[Bug libfortran/26252] FAIL: gfortran.fortran-torture/execute/nan_inf_fmt.f90 execution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26252 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED CC||fxcoudert at gcc dot ||gnu.org Resolution||FIXED --- Comment #16 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org 2011-11-07 22:58:18 UTC --- The testcase appears to pass in recent testresults on this platform (http://gcc.gnu.org/ml/gcc-testresults/2011-09/msg01343.html), so I'm closing the PR.
[Bug libfortran/26252] FAIL: gfortran.fortran-torture/execute/nan_inf_fmt.f90 execution
--- Comment #13 from danglin at gcc dot gnu dot org 2008-03-22 17:17 --- I started looking at the effect of the changes suggested in comment #10 using a recently completed 4.3.0 build. However, I realized this morning that nan_inf_fmt.f90 isn't failing with 4.3, http://gcc.gnu.org/ml/gcc-testresults/2008-03/msg01551.html. However, the gfortran.dg/nan_3.f90 fail may be related. The fail is still present in 4.2.3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26252
[Bug libfortran/26252] FAIL: gfortran.fortran-torture/execute/nan_inf_fmt.f90 execution
--- Comment #14 from fxcoudert at gcc dot gnu dot org 2008-03-22 19:41 --- So, if I get this straight, the current status of gfortran on hppa-hpux (4.4 and 4.3) is: - gfortran.dg/nint_2.f90 failing everywhere - gfortran.dg/integer_exponentiation_2.f90 and gfortran.dg/parameter_array_init_3.f90 failing only on hppa64-hp-hpux11.11 - gfortran.dg/include_2.f90, gfortran.dg/integer_exponentiation_4.f90, gfortran.dg/namelist_42.f90 and gfortran.dg/nan_3.f90 failing only on hppa1.1-hp-hpux10.20 (There is a gfortran.dg/ldist-1.f90 failure, but it's not specific to hppa-hpux.) Now, some analysis: - integer_exponentiation_4.f90 is tracked as PR33584; the failure happens on GMP, which suggest a miscompiled GMP or MPFR, see my questions there - nint_2.f90 is PR33595; I think it is a bug in either the system math library, or one of libgfortran's fallback libm functions being incorrect - integer_exponentiation_2.f90 is PR31832, probably a libm bug (see comment #1 in that PR) - for namelist_42.f90 and nan_3.f90, I see you've opened new PRs, thanks - for include_2.f90, I think a simple look at the testsuite log will tell us what happens. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26252
[Bug libfortran/26252] FAIL: gfortran.fortran-torture/execute/nan_inf_fmt.f90 execution
--- Comment #15 from dave at hiauly1 dot hia dot nrc dot ca 2008-03-22 20:29 --- Subject: Re: FAIL: gfortran.fortran-torture/execute/nan_inf_fmt.f90 execution - for include_2.f90, I think a simple look at the testsuite log will tell us what happens. This might be caused by collect2 trying to use gfortran to compile C code. See the attachment for PR 35665. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26252
[Bug libfortran/26252] FAIL: gfortran.fortran-torture/execute/nan_inf_fmt.f90 execution
--- Comment #10 from fxcoudert at gcc dot gnu dot org 2008-03-01 12:08 --- (In reply to comment #7) I tried the attached change. It results in the correct configure results. However, the test still fails. By my reading, this patch will change nothing: it's OK for HAVE_BROKEN_ISFINITE not be defined if isfinite is not defined, because we then have: #if defined(HAVE_BROKEN_ISFINITE) || defined(__CYGWIN__) #undef isfinite #endif #if !defined(isfinite) // define isfinite #endif So, in your case, when isfinite and fpclassify are both functions (and not macros), we're going to simply define isfinite as: #define isfinite(x) ((x) - (x) == 0) David, when you have time, can you test the two following replacements: #define isnan(x)__builtin_expect ((x) != (x), 0) #define isfinite(x) __builtin_expect (!isnan((x) - (x)), 1) #define isinf(x) __builtin_expect (!isnan(x) !isfinite(x), 0) and #define isnan(x)__builtin_isnan (x) #define isfinite(x) __builtin_isfinite (x) #define isinf(x)__builtin_isinf (x) (they should go in libgfortran/libgfortran.h and replace the following block of code: #if defined(HAVE_BROKEN_ISFINITE) || defined(__CYGWIN__) ... #define isnan(x) (fpclassify(x) == FP_NAN) #endif /* !defined(fpclassify) */ #endif /* !defined(isfinite) */ Thanks, FX -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26252
[Bug libfortran/26252] FAIL: gfortran.fortran-torture/execute/nan_inf_fmt.f90 execution
--- Comment #11 from dave at hiauly1 dot hia dot nrc dot ca 2008-03-01 13:42 --- Subject: Re: FAIL: gfortran.fortran-torture/execute/nan_inf_fmt.f90 execution So, in your case, when isfinite and fpclassify are both functions (and not macros), we're going to simply define isfinite as: #define isfinite(x) ((x) - (x) == 0) This is not correct. isfinite and fpclassify are both macros on HP-UX 11. However, they are broken because they only support float and double, and not long double. The function implementations are _Isfinitef, _Isfinite, _Fpclassifyf and _Fpclassify. There's also _Fpclassifyfd where the float argument is cast to double in math.h. On HP-UX 10, there is no isfinite macro or function. There are functions finite and finitef. Likewise, there are fpclassify and fpclassifyf functions. As with HP-UX 11, there is no long double support. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26252
[Bug libfortran/26252] FAIL: gfortran.fortran-torture/execute/nan_inf_fmt.f90 execution
--- Comment #12 from fxcoudert at gcc dot gnu dot org 2008-03-01 13:57 --- (In reply to comment #11) This is not correct. isfinite and fpclassify are both macros on HP-UX 11. However, they are broken because they only support float and double, and not long double. I was focusing on hpux10, because it's what it's in the target field of the bugzilla. But, long double shouldn't be a problem because the testcase only uses float and double (and, while we used to cast everything to long double in libgfortran, we don't do it anymore because of the problems that raised). On HP-UX 10, there is no isfinite macro or function. There are functions finite and finitef. Likewise, there are fpclassify and fpclassifyf functions. So, on hpux10 my point still stands, doesn't it? We don't need the _BROKEN macros set, because is the macros aren't defined, we're gonna use their own (whether there are functions or not). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26252
[Bug libfortran/26252] FAIL: gfortran.fortran-torture/execute/nan_inf_fmt.f90 execution
--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2007-08-11 13:05 --- Subject: Re: FAIL: gfortran.fortran-torture/execute/nan_inf_fmt.f90 execution write_float uses isfinite (n) and isnan (n) to determine if Infinite or NaN is emitted and in that case exits before calling output_float. So if execution is reaching output_float, one or both of the aforementioned functions is probably broken or configured incorrectly. I tried the attached change. It results in the correct configure results. However, the test still fails. So, probably the isfinite and isnan defines in libgfortran.h need checking. Don't have time to look at this until week after next. Regard write_float, it looks as if output_float will be called without any finite or nan checks for B, O and Z formats. Dave --- Comment #8 from dave at hiauly1 dot hia dot nrc dot ca 2007-08-11 13:05 --- Created an attachment (id=14052) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14052action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26252
[Bug libfortran/26252] FAIL: gfortran.fortran-torture/execute/nan_inf_fmt.f90 execution
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2007-08-11 15:04 --- Regarding comment #7, The finite and nan have no meaning in the context of binary, octal, or hex output. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26252
[Bug libfortran/26252] FAIL: gfortran.fortran-torture/execute/nan_inf_fmt.f90 execution
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2007-08-09 21:56 --- Still can't reproduce this on hppa2.0w-hp-hpux11.31. I'm starting to think that printf might be broken there, after all. Since it's a corner case on a platform that is not the current one, I'd like to close it as WONTFIX, John, what do you think? -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26252
[Bug libfortran/26252] FAIL: gfortran.fortran-torture/execute/nan_inf_fmt.f90 execution
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2007-08-10
00:41 ---
Subject: Re: FAIL: gfortran.fortran-torture/execute/nan_inf_fmt.f90 execution
Still can't reproduce this on hppa2.0w-hp-hpux11.31. I'm starting to think
that
printf might be broken there, after all. Since it's a corner case on a
platform
that is not the current one, I'd like to close it as WONTFIX, John, what do
you
think?
I just happened to have an old build of 4.2.0 lying around. The failure
is caused by a segmentation fault:
Program received signal SIGSEGV, Segmentation fault.
0x328a8 in atoi () at lib2funcs.asm:77
77 lib2funcs.asm: No such file or directory.
Current language: auto; currently asm
(gdb) bt
#0 0x328a8 in atoi () at lib2funcs.asm:77
#1 0x1d5a4 in output_float (dtp=0x7b03b2c0, f=0x4001bd10, value=-nan)
at ../../../gcc/libgfortran/io/write.c:557
#2 0x1dfbc in write_float (dtp=0x0, f=0x0,
source=0x7b03b950 \004üGÙ{\003¸{\003·ø\006\002ÿÿ, len=2063841318)
at ../../../gcc/libgfortran/io/write.c:973
#3 0xdcf0 in formatted_transfer (dtp=0x7b03b2c0, type=BT_REAL, p=0x7b03b950,
kind=4, size=4, nelems=1) at ../../../gcc/libgfortran/io/transfer.c:1086
#4 0xc5c8 in *_gfortran_transfer_real (dtp=0x7b03b2c0, p=0x7b03b290, kind=4)
at ../../../gcc/libgfortran/io/transfer.c:1369
#5 0x9d74 in MAIN__ ()
at
/xxx/gnu/gcc/gcc/gcc/testsuite/gfortran.fortran-torture/execute/nan_inf_fmt.f90:19
#6 0xae3c in main (argc=1, argv=0x7b03b048)
at ../../../gcc/libgfortran/fmain.c:18
The 11.11 manpage for printf says:
The e, f, and g conversions will print inf for infinity and nan for
both quiet and signaling NaN values.
The 10.20 manpage doesn't say anything about this but sprintf returned
+inf followed by ' ' 42 times. Obviously, somewhat broken... However,
output_float doesn't seem to handle returns of inf or nan.
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26252
[Bug libfortran/26252] FAIL: gfortran.fortran-torture/execute/nan_inf_fmt.f90 execution
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-08-10 03:00 --- write_float uses isfinite (n) and isnan (n) to determine if Infinite or NaN is emitted and in that case exits before calling output_float. So if execution is reaching output_float, one or both of the aforementioned functions is probably broken or configured incorrectly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26252
[Bug libfortran/26252] FAIL: gfortran.fortran-torture/execute/nan_inf_fmt.f90 execution
--- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2007-08-10 04:42 --- Subject: Re: FAIL: gfortran.fortran-torture/execute/nan_inf_fmt.f90 execution write_float uses isfinite (n) and isnan (n) to determine if Infinite or NaN is emitted and in that case exits before calling output_float. So if execution is reaching output_float, one or both of the aforementioned functions is probably broken or configured incorrectly. It looks like the configure tests are broken: checking whether isfinite is broken... no checking whether isnan is broken... no checking whether fpclassify is broken... no The cross compile settings are broken. hpux10 doesn't have the isfinite, isnan or fpclassify macros. The available checks are the finite, isnan and fpclassify functions for doubles; finitef, and isnanf and fpclassifyf for floats. There are no functions for long doubles. Looking at the configure tests, I think they should return 1 when the macros don't exist. hpux11 has macros when -D_HPUX_SOURCE is defined. However, there is no long double support. So, the configure tests probably correctly fail. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26252
[Bug libfortran/26252] FAIL: gfortran.fortran-torture/execute/nan_inf_fmt.f90 execution
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-02-16 16:21:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26252
[Bug libfortran/26252] FAIL: gfortran.fortran-torture/execute/nan_inf_fmt.f90 execution
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-02-17 19:34 --- I can't reproduce that on hppa2.0w-hp-hpux11.23. I don't know if it's a difference between hpux version, or hppa1 and hppa2 (well, I don't know what these two are really), but I'd guess it's the OS version. I don't have access to a hpux10. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26252
[Bug libfortran/26252] FAIL: gfortran.fortran-torture/execute/nan_inf_fmt.f90 execution
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2006-02-17 20:51 --- Subject: Re: FAIL: gfortran.fortran-torture/execute/nan_inf_fmt.f90 execution I can't reproduce that on hppa2.0w-hp-hpux11.23. I don't know if it's a difference between hpux version, or hppa1 and hppa2 (well, I don't know what these two are really), but I'd guess it's the OS version. I don't have access to a hpux10. The default for all 32-bit hppa targets is to generate PA 1.1 code. There's some difference in scheduling between different processor families but for the most part the code for hppa2.0w and hppa1.1 should be similar. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26252
