Executing on host: /users/bin/gcc/gcc-4.1/objdir/gcc/testsuite/../gfortran -B/us ers/bin/gcc/gcc-4.1/objdir/gcc/testsuite/../ /users/bin/gcc/gcc-4.1/gcc/gcc/test suite/gfortran.fortran-torture/execute/nan_inf_fmt.f90 -w -O0 -L/users/bin/g cc/gcc-4.1/objdir/hppa1.1-hp-hpux10.20/./libgfortran/.libs -L/users/bin/gcc/gcc- 4.1/objdir/hppa1.1-hp-hpux10.20/./libgfortran/.libs -L/users/bin/gcc/gcc-4.1/obj dir/hppa1.1-hp-hpux10.20/./libiberty -lm -o /users/bin/gcc/gcc-4.1/objdir/gcc /testsuite/nan_inf_fmt.x (timeout = 600) PASS: gfortran.fortran-torture/execute/nan_inf_fmt.f90 compilation, -O0 Setting LD_LIBRARY_PATH to .:/users/bin/gcc/gcc-4.1/objdir/hppa1.1-hp-hpux10.20/ ./libgfortran/.libs:/users/bin/gcc/gcc-4.1/objdir/hppa1.1-hp-hpux10.20/./libgfor tran/.libs:/users/bin/gcc/gcc-4.1/objdir/gcc:.:/users/bin/gcc/gcc-4.1/objdir/hpp a1.1-hp-hpux10.20/./libgfortran/.libs:/users/bin/gcc/gcc-4.1/objdir/hppa1.1-hp-h pux10.20/./libgfortran/.libs:/users/bin/gcc/gcc-4.1/objdir/gcc At line 19 of file /users/bin/gcc/gcc-4.1/gcc/gcc/testsuite/gfortran.fortran-tor ture/execute/nan_inf_fmt.f90 Internal Error: printf is broken FAIL: gfortran.fortran-torture/execute/nan_inf_fmt.f90 execution, -O0
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.
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
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?
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
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.
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
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
Created attachment 14052 [details] acinclude.m4.d
Regarding comment #7, The finite and nan have no meaning in the context of binary, octal, or hex output.
(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
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
(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).
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.
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.
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
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.