[Bug fortran/107716] New: Getting negative values with NINT when using doubleprecision values in range on i386

[Bug fortran/107716] New: Getting negative values with NINT when using doubleprecision values in range on i386

[urbanjost at comcast dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107716

            Bug ID: 107716
           Summary: Getting negative values with NINT when using
                    doubleprecision values in range on i386
           Product: gcc
           Version: 11.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: urbanjost at comcast dot net
  Target Milestone: ---

[Bug fortran/107716] Getting negative values with NINT when using doubleprecision values in range on i386

[urbanjost at comcast dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107716

--- Comment #1 from urbanjost at comcast dot net ---
I am on a Linux mint box using KVM and
running a virtual box that is
   OpenBSD mo.my.domain 7.2 GENERIC#381 i386
using
   GNU Fortran (GCC) 11.2.0
and am getting negative values from NINT()
on doubleprecision values when I do not expect
them.

I thought NINT() took any KIND of REAL so I did
not expect that; but it has been a while since
I ran on i386, and I am on a virtual box.

If I do a NINT(REAL(value)) instead of NINT(value)
I get the expected INTEGER value.

Any reason I should expect NINT() to not work
with values still within the range of the default
INTEGER kind?

Anyone have a 32-bit box with gfortran on it that
could see if they start getting negative values
with doubleprecision input values below HUGE(0)?

     >   program testit
     >   use,intrinsic :: iso_fortran_env, only : int8, int16, int32, int64
     >   use,intrinsic :: iso_fortran_env, only : real32, real64, real128
     >   implicit none
     >   doubleprecision :: value
     >   integer :: i
     >   do i=0,huge(0)-1
     >   value=i
     >   if(nint(value).lt.0)then
     >      write(*,*)'VALUE:',value
     >      write(*,*)'REAL(VALUE):',real(value)
     >      write(*,*)'NINT(REAL(VALUE)):',nint(real(value))
     >      write(*,*)'NINT(VALUE):',nint(value-1)
     >      write(*,*)'NINT(VALUE):',nint(value)
     >      write(*,*)'NINT(VALUE):',nint(value+1)
     >      write(*,*)'INT:',int(value-1)
     >      write(*,*)'INT:',int(value)
     >      write(*,*)'INT:',int(value+1)
     >      exit
     >   endif
     >   enddo
     >   write(*,*)'value:',value
     >   write(*,*)'huge(0):',huge(0)
     >   write(*,*)'huge(0_int64):',huge(0_int64)
     >   write(*,*)'huge(0_int32):',huge(0_int32)
     >   write(*,*)'huge(0_int16):',huge(0_int16)
     >   write(*,*)'huge(0_int8):',huge(0_int8)
     >   end program testit
     >   
     >    VALUE:   2097153.0000000000     
     >    REAL(VALUE):   2097153.00    
     >    NINT(REAL(VALUE)):     2097153
     >    NINT(VALUE):     2097152
     >    NINT(VALUE):          -1
     >    NINT(VALUE):     2097154
     >    INT:     2097152
     >    INT:     2097153
     >    INT:     2097154
     >    value:   2097153.0000000000     
     >    huge(0):  2147483647
     >    huge(0_int64):  9223372036854775807
     >    huge(0_int32):  2147483647
     >    huge(0_int16):  32767
     >    huge(0_int8):  127


It starts off with just odd numbers getting a -1 return

[Bug fortran/107716] Getting negative values with NINT when using doubleprecision values in range on i386

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107716

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
           Priority|P3                          |P4
                 CC|                            |kargl at gcc dot gnu.org
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2022-11-16

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to urbanjost from comment #1)
> I am on a Linux mint box using KVM and
> running a virtual box that is
>    OpenBSD mo.my.domain 7.2 GENERIC#381 i386
>

It seems that you may have discovered a bug in OpenBSD.

% cat a.f90
function ibar(x) result(r)
   integer r
   real x
   r = nint(x)
end function

% cat a.f90.005t.original 
__attribute__((fn spec (". w ")))
integer(kind=4) ibar (real(kind=4) & restrict x)
{
  integer(kind=4) r;

  r = __builtin_iroundf (*x);
  return r;
}

% grep call a.s
        call    lroundf

So, at least on FreeBSD, nint() is mapped to lroundf() from libm.

[Bug fortran/107716] Getting negative values with NINT when using doubleprecision values in range on i386

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107716

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|WAITING                     |RESOLVED

--- Comment #3 from anlauf at gcc dot gnu.org ---
Not a gcc bug.  Please report to OpenBSD.

[Bug fortran/107716] Getting negative values with NINT when using doubleprecision values in range on i386

[xry111 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107716

Xi Ruoyao <xry111 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|INVALID                     |MOVED
                 CC|                            |xry111 at gcc dot gnu.org

[Bug fortran/107716] Getting negative values with NINT when using doubleprecision values in range on i386

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107716

--- Comment #4 from kargl at gcc dot gnu.org ---
What the heck does "RESOLVED MOVED"?

[Bug fortran/107716] Getting negative values with NINT when using doubleprecision values in range on i386

[mikael at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107716

Mikael Morin <mikael at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mikael at gcc dot gnu.org

--- Comment #5 from Mikael Morin <mikael at gcc dot gnu.org> ---
(In reply to kargl from comment #4)
> What the heck does "RESOLVED MOVED"?

I think it means this PR is not a gcc bug and the problem is tracked on some
other project's bug tracker (it is "moved" there).

Not sure where else the problem is tracked in this case.

[Bug fortran/107716] Getting negative values with NINT when using doubleprecision values in range on i386

[sgk at troutmask dot apl.washington.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107716

--- Comment #6 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Wed, Sep 20, 2023 at 07:07:37PM +0000, mikael at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107716
> 
> --- Comment #5 from Mikael Morin <mikael at gcc dot gnu.org> ---
> (In reply to kargl from comment #4)
> > What the heck does "RESOLVED MOVED"?
> 
> I think it means this PR is not a gcc bug and the problem is tracked on some
> other project's bug tracker (it is "moved" there).
> 
> Not sure where else the problem is tracked in this case.
> 

Thanks, Mikael.  After a bit of duck-duck-go, I've come to a
similar conclusion.

<$0.02>
If a url/pointer to where the bug is actually tracked is not available,
this status should not be used.  It is useless.  I'll also note that if
one clicks on the 'status:' label a list of stati (statuses?) and their
meaining can be found.  MOVED is not among the list.
</$0.02>