I expect that when compilers begin to more widely support 16-bit and 128-bit floating point, there is going to be confusion among some programmers between REAL16, REAL(16), and REAL*16, particularly within legacy codes or when mixing legacy and new codes.
It might also be mentioned that gfortran sets the value of REAL16 to be -2. That means that gfortran does not support a 16-bit floating point format, but that there is a more precise real kind available (three of them, in this case).
It might have something to do with GPL licensing of the underlying multiprecision library.
As far as building software from source (tarball, gitlab, etc.), there are both advantages and disadvantages to using a package manager. The advantage is that it installs and updates automatically all of the prerequisit software that you need without the installer needing to know those details for each installation. The disadvantages are that the latest distributions are not available immediately through the package manager when they become available on gitlab, and, for example in this case, the installer might want to customize some of the build options.
Sure it is not. I used it just to make the example as concise as possible.
So we have somewhat strange situation where real128 does have support but is not defined by default (or, at least in the easy-accessible repository) and at the same time int128 does not have full working support but is enabled.
I’ve only recently begun to use flang so I don’t know its history. I suspect that both REAL128 and INT128 support are more recent additions to the compiler. It appears that allowing allocatables recursively within a derived type is also a recent addition, and that parameterized data types are still not fully supported. If so, then we as programmers should applaud these newly added features while being, let’s say “constructive”, with our criticisms.
[edit] Here is an integer pow(i,j) function written in fortran that uses recursive squaring in case this is useful for anyone. It does not attempt to handle efficiently the border cases (i==0, j==0, j<0, and so on), just the straightforward ones.
program power
use, intrinsic :: iso_fortran_env, only: ik => int128
implicit none
integer(ik) :: two=2_ik, y, val
integer :: j
val = 1_ik
do j = 0, (bit_size(y)-2)
y = pow(two,j)
write(*,*) 'j=', j, ' y=', y, ' error=', (y-val)
val = val * two
enddo
contains
pure function pow( i, j )
! compute i**j with recursive squaring.
implicit none
integer(ik) :: pow
integer(ik), intent(in) :: i
integer, intent(in) :: j
integer(ik) :: t
integer :: pos
intrinsic :: bit_size, leadz, btest
pow = 1_ik
t = i
do pos = 0, (bit_size(j) - leadz(j) -1)
if ( btest(j,pos) ) pow = pow * t
t = t * t
enddo
end function pow
end program power