https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96711
kargl at gcc dot gnu.org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kargl at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed| |2020-08-19 Status|UNCONFIRMED |NEW --- Comment #4 from kargl at gcc dot gnu.org --- (In reply to B Eggen from comment #3) > Here is the latest f90 file: > > program nint_error > > integer :: n, m > integer(kind=16) :: i, j, nint > > integer, parameter :: idp=selected_real_kind(9,99) > integer, parameter :: i16=selected_int_kind(38) > > real(kind=idp) :: x, y > > write(*,'(*(g0:" "))') 'i16=', i16, huge(i) > i=1_16 > x=1.0d0 > do n=1, 128, 1 > j=i-1_16 > y=x-1.0d0 > m=nint(y) ! this compiles, but gives wrong results > ! m=nint(y,i16) ! this will generate an internal compiler error > write(*,'(*(g0:" "))') n, i, x, m > i=i+i > x=x+x > if ( (m<1) .and. (n>3)) exit > end do > > do i=2147483647_16-10_16, 2147483648_16+10_16, 1_16 > x=dble(i) > m=nint(x) > write(*,'(*(g0:" "))') i, x, m > end do > > > stop > end program nint_error It is somewhat hard to decipher what the problem. You have conflated correct behavior with that of an apparent. First, m = nint(y) will return a default integer. From 16.9.141 Result Characteristics. Integer. If KIND is present, the kind type parameter is that specified by the value of KIND; otherwise, the kind type parameter is that of default integer type. on your target the default integer kind is 4 (i.e., a 32-bit signed integer). This means that 32 2147483648 2147483648.0000000 2147483647 33 4294967296 4294967296.0000000 -1 your program becomes nonconforming for n = 33. The Fortran standard contains A program shall not invoke an intrinsic procedure under circumstances where a value to be assigned to a subroutine argument or returned as a function result is not representable by objects of the specified type and type parameters. The function result of 4294967296 is technically not representable (except that you're getting twos-complement wrap around). As to your observation about IDNINT. It is a specific name for the generic intrinsic NINT. It has one double precision argument. It does not have a kind argument. Now, onto the bug. It can be distilled down to program nint_error implicit none integer(kind=16) :: m real(8) :: x, y x = 1 y = x - 1 m = nint(y,16) end program nint_error % gfcx -o z a.f90 && ./z a.f90:9:0: 9 | m = nint(y,16) | internal compiler error: in build_round_expr, at fortran/trans-intrinsic.c:396 0x5bd9fa build_round_expr ../../gccx/gcc/fortran/trans-intrinsic.c:396 0x5bd9fa build_fix_expr ../../gccx/gcc/fortran/trans-intrinsic.c:420 0x8c7bf2 gfc_conv_intrinsic_int ../../gccx/gcc/fortran/trans-intrinsic.c:550 It would seem that a fold_convert to an appropriate kind is missing.