[Bug fortran/48979] FRACTION und EXPONENT return invalid results for infinity/NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48979 --- Comment #19 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- Author: fxcoudert Date: Sun Oct 19 20:49:27 2014 New Revision: 216443 URL: https://gcc.gnu.org/viewcvs?rev=216443root=gccview=rev Log: PR fortran/48979 * trans-const.c (gfc_build_nan): New function. * trans-const.h (gfc_build_nan): New prototype. * trans-intrinsic.c (gfc_conv_intrinsic_exponent): Handle special values. (gfc_conv_intrinsic_minmaxval): Use gfc_build_nan. (gfc_conv_intrinsic_fraction): Handle special values. (gfc_conv_intrinsic_spacing): Likewise. (gfc_conv_intrinsic_rrspacing): Likewise. (gfc_conv_intrinsic_set_exponent): Likewise. * gfortran.dg/ieee/intrinsics_2.F90: New test. Added: trunk/gcc/testsuite/gfortran.dg/ieee/intrinsics_2.F90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-const.c trunk/gcc/fortran/trans-const.h trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/48979] FRACTION und EXPONENT return invalid results for infinity/NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48979 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #20 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- Fully fixed on trunk.
[Bug fortran/48979] FRACTION und EXPONENT return invalid results for infinity/NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48979 --- Comment #18 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- Author: fxcoudert Date: Sat Oct 11 16:57:32 2014 New Revision: 216120 URL: https://gcc.gnu.org/viewcvs?rev=216120root=gccview=rev Log: PR fortran/48979 * simplify.c (gfc_simplify_atan): Use mpfr_zero_p to check for zeros. (gfc_simplify_log): Likewise. (gfc_simplify_scale): Likewise. (gfc_simplify_exponent): Handle infinities and NaNs. (gfc_simplify_fraction): Handle infinities. (gfc_simplify_rrspacing): Handle signed zeros and NaNs. (gfc_simplify_set_exponent): Handle infinities and NaNs. (gfc_simplify_spacing): Handle zeros, infinities and NaNs. * gfortran.dg/ieee/intrinsics_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/ieee/intrinsics_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/simplify.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/48979] FRACTION und EXPONENT return invalid results for infinity/NaN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48979 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |ASSIGNED CC||fxcoudert at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |fxcoudert at gcc dot gnu.org
[Bug fortran/48979] FRACTION und EXPONENT return invalid results for infinity/NaN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48979 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-01-07 Ever confirmed|0 |1 --- Comment #17 from Dominique d'Humieres dominiq at lps dot ens.fr --- What is the fate of the patches in comments 6, 7, 10, ... ?
[Bug fortran/48979] FRACTION und EXPONENT return invalid results for infinity/NaN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48979 Sean Santos quantheory at gmail dot com changed: What|Removed |Added CC||quantheory at gmail dot com --- Comment #16 from Sean Santos quantheory at gmail dot com 2013-04-14 21:28:27 UTC --- Regarding the above comment: You need to have IEEE_EXCEPTIONS or IEEE_ARITHMETIC loaded *in the scoping unit*, if you want to use IEEE 754 features. Well, yes and no. There are three cases: 1) If you don't access those modules in a particular scope, it is processor-dependent (e.g. up to the compiler) whether IEEE features are supported. They can be on or off all the time, or there can be a compiler option. 2) If you do access those modules, it is *still* processor-dependent whether IEEE features are supported, so that doesn't change. However, this does change: i) The compiler is allowed to change the level of IEEE support. It is explicitly allowed to change the degree of support for exceptions. I don't think that the committee actually intended for support of IEEE NaN and Inf to change based on whether or not IEEE_ARITHMETIC is in scope, but technically the standard seems to allow it. ii) If IEEE_ARITHMETIC is provided, the compiler is required to provide the IEEE_SUPPORT_* functions so that the program can query them. (However, it is not supposed to enforce their use at compile time.) 3) If you access IEEE_ARITHMETIC and use IEEE_NAN and IEEE_INF from IEEE_FEATURES, the compiler is required to do one of only three things: i) Error at compile time because it doesn't have one or both modules. ii) Error at compile time because it has IEEE_FEATURES, but the module doesn't contain IEEE_NAN/IEEE_INF. iii) Enable support of IEEE_NAN and IEEE_INF in the scope. TLDR: If the compiler declares that it doesn't actually have any IEEE support (which it implicitly does by not providing these modules), it can do anything it wants. If IEEE_FEATURES was provided, that should probably be used to turn on IEEE features that are turned off by default because they are inefficient, not IEEE_ARITHMETIC. If an IEEE feature isn't a significant performance hit, it may as well be on all the time.
[Bug fortran/48979] FRACTION und EXPONENT return invalid results for infinity/NaN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48979 --- Comment #14 from kargl at gcc dot gnu.org 2011-05-22 23:02:01 UTC --- Created attachment 24333 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24333 patch for simplification
[Bug fortran/48979] FRACTION und EXPONENT return invalid results for infinity/NaN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48979 --- Comment #15 from kargl at gcc dot gnu.org 2011-05-22 23:03:22 UTC --- (In reply to comment #14) Created attachment 24333 [details] patch for simplification I doubt that I'll be able to go beyond this. I'm not clever enough nor fluent enough with trees to fix the issues in trans-intrinsics.c.
[Bug fortran/48979] FRACTION und EXPONENT return invalid results for infinity/NaN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48979 --- Comment #11 from Thomas Henlich thenlich at users dot sourceforge.net 2011-05-13 09:13:01 UTC --- Mind the change between F2003 and F2008: F2003: FRACTION(+Inf) = +Inf FRACTION(-Inf) = -Inf F2008: FRACTION(+Inf) = NaN FRACTION(-Inf) = NaN And I think what If X is an IEEE NaN, the result is that NaN. means is: IF ISNAN(X) FRACTION(X) = X which is different from IF ISNAN(X) FRACTION(X) = Z'7FC0'
[Bug fortran/48979] FRACTION und EXPONENT return invalid results for infinity/NaN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48979
--- Comment #12 from Tobias Burnus burnus at gcc dot gnu.org 2011-05-13
09:42:02 UTC ---
(In reply to comment #11)
Mind the change between F2003 and F2008:
F2003:
FRACTION(+Inf) = +Inf
F2008:
FRACTION(+Inf) = NaN
See http://j3-fortran.org/doc/year/07/07-200r1.txt for that change (cf. also
http://www.j3-fortran.org/doc/meeting/186/08-287r2.txt ).
However, I think it makes sense to stick to the F2008 value - and ignore F2003.
+ if (mpfr_nan_p (x-value.real) != 0 || mpfr_inf_p (x-value.real) != 0)
+{
+ mpfr_set (result-value.real, x-value.real, GFC_RND_MODE);
+ if (gfc_option.allow_std (GFC_STD_F2008|GFC_STD_F2003))
+ return result;
+ return range_check (result, FRACTION);
+}
+
Regarding the coding:
* if (gfc_option.allow_std (GFC_STD_F2008|GFC_STD_F2003))
Better: gfc_option.allow_std GFC_STD_F2003) - later standards imply
earlier ones.
* mpfr_set (result-value.real, x-value.real, GFC_RND_MODE);
Better: mpfr_set_nan (result-value.real);
I still miss that -frange-check is mentioned in the error messages produced by
range_check() - and I am not really convinced that (a) the error should be
conditional on -std=f95 and (b) that having a -frange-check enabled by default
is a bad idea. I think many code problems have been found that way - and if the
flag is mentioned in the error message, those few codes which need it, can
simply disable the check.
Side note: If I understand F2003/F2008's IEEE support correctly (that's a big
if): You need to have IEEE_EXCEPTIONS or IEEE_ARITHMETIC loaded *in the scoping
unit*, if you want to use IEEE 754 features. Additionally, a query for
IEEE_SUPPORT_INF and/or IEEE_SUPPORT_NAN had to return .true. in order that
those can be expected to be supported. In that sense: As the program does not
load a IEEE module, it cannot use NAN/INF and the compile-time error is
standard conforming ;-)
[Bug fortran/48979] FRACTION und EXPONENT return invalid results for infinity/NaN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48979
--- Comment #13 from Steve Kargl sgk at troutmask dot apl.washington.edu
2011-05-13 14:49:52 UTC ---
On Fri, May 13, 2011 at 10:10:42AM +, burnus at gcc dot gnu.org wrote:
+ if (mpfr_nan_p (x-value.real) != 0 || mpfr_inf_p (x-value.real) != 0)
+{
+ mpfr_set (result-value.real, x-value.real, GFC_RND_MODE);
+ if (gfc_option.allow_std (GFC_STD_F2008|GFC_STD_F2003))
+ return result;
+ return range_check (result, FRACTION);
+}
+
Regarding the coding:
* if (gfc_option.allow_std (GFC_STD_F2008|GFC_STD_F2003))
Better: gfc_option.allow_std GFC_STD_F2003) - later standards imply
earlier ones.
OK.
* mpfr_set (result-value.real, x-value.real, GFC_RND_MODE);
Better: mpfr_set_nan (result-value.real);
As Thomas points out, the Standards that it X is an IEEE NaN,
then FRACTION(X) is that NaN. The mpfr_set() should be simply
copying the NaN into the result [1]. mpfr_set_nan() may not be
the same NaN. From the ieee754 standard (when Fortran 2003/2008)
were written, we have for a 32-bit floating point NaN
If e = 255 and f != 0 , then v is NaN regardless of s
Here, e is a biased exponent and f is the significand. Therefore,
there are 2**24 possible values for f and hence NaN.
[1] Arg. I just looked at a reduced test based on Thomas code. I
get
troutmask:sgk[214] gfc4x -o z g1.f90 ./z
NaN 7FD0NaN 7FD0 0
NaN 7FD0NaN 7FC0 0
so the rounding with mpfr_set seems to be effecting the copying
of the x into the result.
I still miss that -frange-check is mentioned in the error messages produced by
range_check() - and I am not really convinced that (a) the error should be
conditional on -std=f95 and (b) that having a -frange-check enabled by default
is a bad idea. I think many code problems have been found that way - and if
the
flag is mentioned in the error message, those few codes which need it, can
simply disable the check.
What to do about range checking is a different issue. Putting
info about -frange-check in the error message would certainly
pre-empt the assumption that people actually read the documentation
provided with their compiler.
[Bug fortran/48979] FRACTION und EXPONENT return invalid results for infinity/NaN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48979 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org 2011-05-12 16:09:39 UTC --- (In reply to comment #0) Bug 1: The program does not compile without -fno-range-check. Can you explain why you think that this is a bug?
[Bug fortran/48979] FRACTION und EXPONENT return invalid results for infinity/NaN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48979 --- Comment #2 from Thomas Henlich thenlich at users dot sourceforge.net 2011-05-12 17:34:27 UTC --- (In reply to comment #1) (In reply to comment #0) Bug 1: The program does not compile without -fno-range-check. Can you explain why you think that this is a bug? I consider it a bug because the result of the expressions FRACTION(Infinity) and FRACTION(NaN) is defined by the Fortran standard, so the compiler should not throw an error on simplifying them. Whether this really is a bug or not depends on whether one thinks that a standard-compliant Fortran program should compile without requiring special options (I do).
[Bug fortran/48979] FRACTION und EXPONENT return invalid results for infinity/NaN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48979 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2011-05-12 17:49:25 UTC --- (In reply to comment #2) Whether this really is a bug or not depends on whether one thinks that a standard-compliant Fortran program should compile without requiring special options (I do). So do I - but the question is whether it is standard conforming. NAN and INF are not Fortran numbers, cf. 13.4 Numeric models. Admittedly, IEEE and Fortran model numbers are widely mixed in the standard. However, strictly speaking, the IEEE functionality is only available if the relevant IEEE module is loaded and the feature is marked as supported. However, I have to admit that the error message should mention -fno-range-check; currently, it does not.
[Bug fortran/48979] FRACTION und EXPONENT return invalid results for infinity/NaN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48979 --- Comment #4 from Steve Kargl sgk at troutmask dot apl.washington.edu 2011-05-12 18:21:46 UTC --- On Thu, May 12, 2011 at 05:53:10PM +, thenlich at users dot sourceforge.net wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48979 --- Comment #2 from Thomas Henlich thenlich at users dot sourceforge.net 2011-05-12 17:34:27 UTC --- (In reply to comment #1) (In reply to comment #0) Bug 1: The program does not compile without -fno-range-check. Can you explain why you think that this is a bug? I consider it a bug because the result of the expressions FRACTION(Infinity) and FRACTION(NaN) is defined by the Fortran standard, so the compiler should not throw an error on simplifying them. Whether this really is a bug or not depends on whether one thinks that a standard-compliant Fortran program should compile without requiring special options (I do). You're looking at the wrong standard. Gfortran is a Fortran 95 compiler (yes, it has many F03 and F08 extensions). The Fortran 95 standard states: 13.14.38 FRACTION(X) Result Value. The result has the value X*b**(-e), where b and e are as defined in 13.7.1 for the model representation of X. If X has the value zero, the result has the value zero. Neither NaN nor +-Inf can be represented as a model number.
[Bug fortran/48979] FRACTION und EXPONENT return invalid results for infinity/NaN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48979 --- Comment #5 from Steve Kargl sgk at troutmask dot apl.washington.edu 2011-05-12 18:47:54 UTC --- On Thu, May 12, 2011 at 05:59:44PM +, burnus at gcc dot gnu.org wrote: Whether this really is a bug or not depends on whether one thinks that a standard-compliant Fortran program should compile without requiring special options (I do). So do I - but the question is whether it is standard conforming. NAN and INF are not Fortran numbers, cf. 13.4 Numeric models. Admittedly, IEEE and Fortran model numbers are widely mixed in the standard. However, strictly speaking, the IEEE functionality is only available if the relevant IEEE module is loaded and the feature is marked as supported. From F2003: Page 300: 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 (section 14) is accessible and there is support for an infinite or a NaN result, as appropriate. Page 364: The intrinsic modules IEEE_EXCEPTIONS, IEEE_ARITHMETIC, and IEEE_FEATURES provide support for exceptions and IEEE arithmetic. Whether the modules are provided is processor dependent. 1) Thomas's program does not USE IEEE_ARITHMETIC. 2) gfortran does not supply the ieee modules. So, calling fraction() with +-Inf and NaN is, I believe, technically non-conforming. I agree that having consistency between constant-folding and runtime results is desirable, I disagree on calling the need for -fno-range-check a bug.
[Bug fortran/48979] FRACTION und EXPONENT return invalid results for infinity/NaN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48979
--- Comment #6 from Steve Kargl sgk at troutmask dot apl.washington.edu
2011-05-12 19:18:16 UTC ---
On Thu, May 12, 2011 at 07:03:34PM +, sgk at troutmask dot
apl.washington.edu wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48979
--- Comment #5 from Steve Kargl sgk at troutmask dot apl.washington.edu
2011-05-12 18:47:54 UTC ---
On Thu, May 12, 2011 at 05:59:44PM +, burnus at gcc dot gnu.org wrote:
Whether this really is a bug or not depends on whether one thinks that a
standard-compliant Fortran program should compile without requiring
special
options (I do).
So do I - but the question is whether it is standard conforming. NAN and INF
are not Fortran numbers, cf. 13.4 Numeric models. Admittedly, IEEE and
Fortran model numbers are widely mixed in the standard. However, strictly
speaking, the IEEE functionality is only available if the relevant IEEE
module
is loaded and the feature is marked as supported.
From F2003:
Page 300:
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 (section 14) is accessible
and there is support for an infinite or a NaN result, as appropriate.
Page 364:
The intrinsic modules IEEE_EXCEPTIONS, IEEE_ARITHMETIC, and
IEEE_FEATURES provide support for exceptions and IEEE arithmetic.
Whether the modules are provided is processor dependent.
1) Thomas's program does not USE IEEE_ARITHMETIC.
2) gfortran does not supply the ieee modules.
So, calling fraction() with +-Inf and NaN is, I believe,
technically non-conforming.
I agree that having consistency between constant-folding
and runtime results is desirable, I disagree on calling the
need for -fno-range-check a bug.
Index: simplify.c
===
--- simplify.c (revision 173705)
+++ simplify.c (working copy)
@@ -2328,6 +2328,12 @@ gfc_simplify_fraction (gfc_expr *x)
result = gfc_get_constant_expr (BT_REAL, x-ts.kind, x-where);
+ if (mpfr_nan_p (x-value.real) != 0 || mpfr_inf_p (x-value.real) != 0)
+{
+ mpfr_set (result-value.real, x-value.real, GFC_RND_MODE);
+ return result;
+}
+
if (mpfr_sgn (x-value.real) == 0)
{
mpfr_set_ui (result-value.real, 0, GFC_RND_MODE);
gives
0.000.00 0
0.000.00 0
NaN 7FD0NaN 7FD0 0
NaN 7FD0NaN 7FC0 0
-Infinity FF80 -Infinity FF80 0
-Infinity FF80 -Infinity FF80 3
Infinity 7F80 Infinity 7F80 0
Infinity 7F80 Infinity 7F80 3
fixing exponent is much more involved.
[Bug fortran/48979] FRACTION und EXPONENT return invalid results for infinity/NaN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48979
--- Comment #7 from Steve Kargl sgk at troutmask dot apl.washington.edu
2011-05-12 20:10:19 UTC ---
Here's a better patch that gets the warning/error
messages correct.
Index: simplify.c
===
--- simplify.c (revision 173705)
+++ simplify.c (working copy)
@@ -2328,6 +2328,12 @@ gfc_simplify_fraction (gfc_expr *x)
result = gfc_get_constant_expr (BT_REAL, x-ts.kind, x-where);
+ if (mpfr_nan_p (x-value.real) != 0 || mpfr_inf_p (x-value.real) != 0)
+{
+ mpfr_set (result-value.real, x-value.real, GFC_RND_MODE);
+ return range_check (result, FRACTION);
+}
+
if (mpfr_sgn (x-value.real) == 0)
{
mpfr_set_ui (result-value.real, 0, GFC_RND_MODE);
[Bug fortran/48979] FRACTION und EXPONENT return invalid results for infinity/NaN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48979 --- Comment #8 from Tobias Burnus burnus at gcc dot gnu.org 2011-05-12 20:36:05 UTC --- (In reply to comment #7) + return range_check (result, FRACTION); Can we additionally add to the range_check() error messages a note like This check can be disabled with the option -fno-range-check? We already did so at several places. I think without, one does not know that one can easily disable it. An alternative would be to switch to the middle-end way of showing warning messages: warning: unused variable 'x' [-Wunused-variable] Analogously, the error could then be [-frange-check].
[Bug fortran/48979] FRACTION und EXPONENT return invalid results for infinity/NaN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48979
--- Comment #10 from Steve Kargl sgk at troutmask dot apl.washington.edu
2011-05-12 20:54:38 UTC ---
Forgot the diff
Index: simplify.c
===
--- simplify.c (revision 173705)
+++ simplify.c (working copy)
@@ -2328,6 +2328,14 @@ gfc_simplify_fraction (gfc_expr *x)
result = gfc_get_constant_expr (BT_REAL, x-ts.kind, x-where);
+ if (mpfr_nan_p (x-value.real) != 0 || mpfr_inf_p (x-value.real) != 0)
+{
+ mpfr_set (result-value.real, x-value.real, GFC_RND_MODE);
+ if (gfc_option.allow_std (GFC_STD_F2008|GFC_STD_F2003))
+ return result;
+ return range_check (result, FRACTION);
+}
+
if (mpfr_sgn (x-value.real) == 0)
{
mpfr_set_ui (result-value.real, 0, GFC_RND_MODE);
[Bug fortran/48979] FRACTION und EXPONENT return invalid results for infinity/NaN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48979 --- Comment #9 from Steve Kargl sgk at troutmask dot apl.washington.edu 2011-05-12 20:53:37 UTC --- On Thu, May 12, 2011 at 08:40:48PM +, burnus at gcc dot gnu.org wrote: (In reply to comment #7) + return range_check (result, FRACTION); Can we additionally add to the range_check() error messages a note like This check can be disabled with the option -fno-range-check? We already did so at several places. I think without, one does not know that one can easily disable it. An alternative would be to switch to the middle-end way of showing warning messages: warning: unused variable 'x' [-Wunused-variable] Analogously, the error could then be [-frange-check]. I worked up the following patch. It now silently accepts fraction() for +-inf and nan for -std=gnu,f2003,f2008. If one uses -std=f95, you get a bunch of noise. I'll finish a patch on Saturday. EXPONENT() is going to be a little more work. When simplication does not apply, gfortran uses something like integer(kind=4) D.1559; integer(kind=4) D.1558; __builtin_frexpf (nan, D.1558); D.1559 = D.1558; _gfortran_transfer_integer_write (dt_parm.2, D.1559, 4); to grab the fraction and exponent. For nan and +-inf, D.1558 is 0.
