[Bug fortran/62245] gfortran miscompiles int() on mips
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=214958root=gccview=rev Log: PR fortran/62245 * intrinsic.texi (INT): clarify result. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/intrinsic.texi
[Bug fortran/62245] gfortran miscompiles int() on mips
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 (8000H) is returned.
[Bug fortran/62245] gfortran miscompiles int() on mips
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
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
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
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
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
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
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
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
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
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.
