[Bug fortran/62245] New: gfortran miscompiles int() on mips

[Bug fortran/62245] New: gfortran miscompiles int() on mips

[jtaylor.debian at googlemail dot com]

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

            Bug ID: 62245
           Summary: gfortran miscompiles int() on mips
           Product: gcc
           Version: 4.9.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jtaylor.debian at googlemail dot com

gfortran miscompiles int() for negative overflows leading to a build
timeout of python-scipy, see #756905
below a testcase, according to
https://gcc.gnu.org/onlinedocs/gfortran/INT.html the result should be
-2147483648

(sid_mips-dchroot)jtaylor@gabrielli:~$ apt-cache  policy gfortran
gfortran:
  Installed: 4:4.9.1-1
  Candidate: 4:4.9.1-1
  Version table:
 *** 4:4.9.1-1 0
        500 http://mirror-ubc.debian.org/debian/ sid/main mips Packages
        100 /var/lib/dpkg/status
(sid_mips-dchroot)jtaylor@gabrielli:~$ cat test.f90
      program add
      implicit none
      real a,b,s
      read *, a
      print *, ' is ' , int(a)
      stop
      end
(sid_mips-dchroot)jtaylor@gabrielli:~$ gfortran test.f90
(sid_mips-dchroot)jtaylor@gabrielli:~$ ./a.out
-1e99
  is   2147483647
Note: The following floating-point exceptions are signalling:
IEEE_INVALID_FLAG IEEE_OVERFLOW_FLAG

[Bug fortran/62245] gfortran miscompiles int() on mips

[Joost.VandeVondele at mat dot ethz.ch]

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

Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Joost.VandeVondele at mat dot ethz
                   |                            |.ch

--- Comment #1 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> ---
well, the docs as well as the standard assume there that all numbers are
representable. 

Note that some compilers (ifort) won't even read -1e99 in a real, as this
exceeds the range of the real, and abort at the read statement.

The behavior on x86 is just following what the hardware does, for example
CVTTSS2SI, and will yield :

 If a converted result is larger than the maximum signed doubleword integer,
the floating-point invalid exception is raised, and if this exception is
masked, the indefinite integer value (80000000H) is returned.

[Bug fortran/62245] gfortran miscompiles int() on mips

[jtaylor.debian at googlemail dot com]

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

--- Comment #2 from Julian Taylor <jtaylor.debian at googlemail dot com> ---
mips is the only architecture with this behavior, all others behave as
documented.
Shouldn't that be reason enough to change mips?
if not please document the exception on mips.

[Bug fortran/62245] gfortran miscompiles int() on mips

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #3 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> ---
(In reply to Julian Taylor from comment #2)
> mips is the only architecture with this behavior, all others behave as
> documented.
> Shouldn't that be reason enough to change mips?
> if not please document the exception on mips.

Not quite, for example on x86 (additionally writing a):

./a.out
1e99
  is          Infinity -2147483648

(note sign).

It is just undefined behavior. 

I assume mips results are correct if the input real fits the range of the
integer ?

[Bug fortran/62245] gfortran miscompiles int() on mips

[jtaylor.debian at googlemail dot com]

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

--- Comment #4 from Julian Taylor <jtaylor.debian at googlemail dot com> ---
no x86 behaves as documented, the documentation states the sign is retained.

You can debate on what largest integer means here, it could be -1 as >
-2147483648 but as positive inputs give -2147483647 I think x86 output is as
intended.

[Bug fortran/62245] gfortran miscompiles int() on mips

[jtaylor.debian at googlemail dot com]

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

--- Comment #5 from Julian Taylor <jtaylor.debian at googlemail dot com> ---
oh I overlooked you put in positive input, thats strange
then the documentation should be updated that its undefined behavior.

[Bug fortran/62245] gfortran miscompiles int() on mips

[Joost.VandeVondele at mat dot ethz.ch]

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

Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> changed:

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

--- Comment #6 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> ---
(In reply to Julian Taylor from comment #5)
> oh I overlooked you put in positive input, thats strange
> then the documentation should be updated that its undefined behavior.

I think the docs are OK, as they follow literally the standard, and neither the
standard nor the gfortran docs usually point out undefined behavior. So I'll
close the report as invalid. Thanks nevertheless.

[Bug fortran/62245] gfortran miscompiles int() on mips

[jtaylor.debian at googlemail dot com]

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

--- Comment #7 from Julian Taylor <jtaylor.debian at googlemail dot com> ---
But the docs indicate that there is no undefined behavior.
As I interpret them the result of int() is always well defined.
If the documentation would not state what happens in the case of overflow it
would be fine to not mention it, but as is one has to know the standard to know
that this part of the documentation is wrong.

[Bug fortran/62245] gfortran miscompiles int() on mips

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #8 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> ---
(In reply to Julian Taylor from comment #7)
> But the docs indicate that there is no undefined behavior.
> As I interpret them the result of int() is always well defined.
> If the documentation would not state what happens in the case of overflow it
> would be fine to not mention it, but as is one has to know the standard to
> know that this part of the documentation is wrong.

I'll submit a patchlet to clarify the wording in the docs (the issue is the use
of range vs magnitude, which suggests defining behavior in the case of
overflow).

[Bug fortran/62245] gfortran miscompiles int() on mips

[jtaylor.debian at googlemail dot com]

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

--- Comment #9 from Julian Taylor <jtaylor.debian at googlemail dot com> ---
thanks, please also clarify/remove the sentence about the sign as the result
sign is not the sign of the input as indicated by the docs.

[Bug fortran/62245] gfortran miscompiles int() on mips

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #10 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> ---
(In reply to Julian Taylor from comment #9)
> thanks, please also clarify/remove the sentence about the sign as the result
> sign is not the sign of the input as indicated by the docs.

it will now include:

The result is undefined if it can not be represented as an @code{INTEGER} of
the given @code{KIND}.

which is explicit.

[Bug fortran/62245] gfortran miscompiles int() on mips

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

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

--- Comment #11 from kargl at gcc dot gnu.org ---
(In reply to Julian Taylor from comment #7)
> But the docs indicate that there is no undefined behavior.
> As I interpret them the result of int() is always well defined.
> If the documentation would not state what happens in the case of overflow it
> would be fine to not mention it, but as is one has to know the standard to
> know that this part of the documentation is wrong.

The standard states (13.7.1)

   A program is prohibited from invoking an intrinsic procedure
   under circumstances where a value to be returned in a subroutine
   argument or function result is outside the range of values
   representable by objects of the specified type and type parameters,
   unless the intrinsic module IEEE ARITHMETIC (clause 14) is
   accessible and there is support for an infnite or a NaN
   result, as appropriate.

a = +-1e99 is outside of the representable range of INTEGER,
so by calling INT(a), your program is nonconforming. gfortran
can do anything and the result is "valid".

[Bug fortran/62245] gfortran miscompiles int() on mips

[vondele at gcc dot gnu.org]

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

--- Comment #12 from vondele at gcc dot gnu.org ---
Author: vondele
Date: Fri Sep  5 13:40:05 2014
New Revision: 214958

URL: https://gcc.gnu.org/viewcvs?rev=214958&root=gcc&view=rev
Log:
        PR fortran/62245
        * intrinsic.texi (INT): clarify result.

Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/intrinsic.texi