Re: Integers and standard



"Steven G. Kargl" <kargl@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:g6nufe$45n$1@xxxxxxxxxxxxxxxxxxxxxxxxxx

The above is consistent with how a BOZ is handled when placed in a
a data statement. If INTEGER(1) is 32-bit and if an INTEGER(2) exists
with larger decimal exponent range, then INT(Z'80000000') will overflow
if you do

INTEGER(1) :: i = INT(Z'80000000')

You seem to be saying that z'80000000' is positive so that converting
it to a signed 32-bit quantity causes overflow, but this seems a bit
imprecise as a description for what happens with gfortran:

C:\gcc_mingw64\clf\ovl>type ovl3.f90
program ovl3
implicit none
integer, parameter :: ik16 = selected_int_kind(38)
integer(ik16) i

! 0 1 2 3 4
! 1234567890123456789012345678901234567890
i = real(z'80000000000000000000000000000000')
write(*,'(z0)') i
end program ovl3

C:\gcc_mingw64\clf\ovl>gfortran ovl3.f90 -oovl3
ovl3.f90:8.47:

i = real(z'80000000000000000000000000000000')
1
Error: Integer too big for integer kind 16 at (1)

real x
x = real(Z'123445678')
end

Should a Fortran processor ignore the leading 1 or the trailing 8 or
assume some 40-bit FP representation with rounding to a 32-bit FP? All
of these are allowed by F2003. gfortran (IMHO) takes the sensible
approach of issuing an error.

troutmask:kargl[203] ~/../sgk/work/4x/bin/gfortran -static -o z g.f90
g.f90:2.12:

x = real(Z'123445678')
1
Error: BOZ constant at (1) is too large (33 vs 32 bits)

But this last behavior is that required by N1723.pdf, section 13.3.3.
Perhaps you should fix it, then :)

--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end


.