The patch 2005-10-03 Francois-Xavier Coudert <coudert@clipper.ens.fr> PR libfortran/19308 PR libfortran/22437 * Makefile.am: Add generated files for large real and integers kinds. Add a rule to create the kinds.inc c99_protos.inc files. Use kinds.inc to preprocess Fortran generated files. * libgfortran.h: Add macro definitions for GFC_INTEGER_16_HUGE, GFC_REAL_10_HUGE and GFC_REAL_16_HUGE. Add types gfc_array_i16, gfc_array_r10, gfc_array_r16, gfc_array_c10, gfc_array_c16, gfc_array_l16. * mk-kinds-h.sh: Define macros HAVE_GFC_LOGICAL_* and HAVE_GFC_COMPLEX_* when these types are available. * intrinsics/ishftc.c (ishftc16): New function for GFC_INTEGER_16. * m4/all.m4, m4/any.m4, m4/count.m4, m4/cshift1.m4, m4/dotprod.m4, m4/dotprodc.m4, m4/dotprodl.m4, m4/eoshift1.m4, m4/eoshift3.m4, m4/exponent.m4, m4/fraction.m4, m4/in_pack.m4, m4/in_unpack.m4, m4/matmul.m4, m4/matmull.m4, m4/maxloc0.m4, m4/maxloc1.m4, m4/maxval.m4, m4/minloc0.m4, m4/minloc1.m4, m4/minval.m4, m4/mtype.m4, m4/nearest.m4, m4/pow.m4, m4/product.m4, m4/reshape.m4, m4/set_exponent.m4, m4/shape.m4, m4/specific.m4, m4/specific2.m4, m4/sum.m4, m4/transpose.m4: Protect generated functions with appropriate "#if defined (HAVE_GFC_type_kind)" preprocessor directives. * Makefile.in: Regenerate. * all files in generated/: Regenerate. has introduced a bunch of regressions on non-C99 SPARC/Solaris platforms: http://gcc.gnu.org/ml/gcc-testresults/2005-10/msg00785.html http://gcc.gnu.org/ml/gcc-testresults/2005-10/msg00786.html http://gcc.gnu.org/ml/gcc-testresults/2005-10/msg00787.html http://gcc.gnu.org/ml/gcc-testresults/2005-10/msg00788.html while SPARC/Solaris 10 is OK: http://gcc.gnu.org/ml/gcc-testresults/2005-10/msg00789.html All almost the failures are: FAIL: gfortran.dg/fold_nearest.f90 -Os (test for excess errors) Excess errors: Undefined first referenced symbol in file _gfortran_nearest_r4 /var/tmp//cckqXPiC.o ld: fatal: Symbol referencing errors. No output written to ./fold_nearest.exe _gfortran_nearest_r4 is missing because it is now guarded with: #if defined (HAVE_GFC_REAL_4) && defined (HAVE_COPYSIGNF) && defined (HAVE_NEXTAFTERF) [...] #endif and neither HAVE_COPYSIGNF nor HAVE_NEXTAFTERF is defined; but of course intrinsics/c99_functions.c provides copysignf and nextafterf. [FX, please make sure your email address as recorded in the ChangeLog file is registered with Bugzilla; same for fxcoudert@gcc.gnu.org. Thanks in advance.]
Confirmed.
(In reply to comment #0) > has introduced a bunch of regressions on non-C99 SPARC/Solaris platforms How come they I don't see those on my sparc-solaris2.9 builds? See http://quatramaran.ens.fr/~coudert/gfortran/test-results/test-sparc-solaris-20051012.log and older. This is particularly annoying, since sparc-solaris2.9 is one of the platforms on which I regtested this patch! Other than that, I concur in diagnosis and solution. Will implement that as soon as possible (most probably on Wednesday evening, European time). > [FX, please make sure your email address as recorded in the ChangeLog file is > registered with Bugzilla; same for fxcoudert@gcc.gnu.org. Thanks in advance.] Sorry, I didn't know that rule. Will use my gcc.gnu.org address in changelogs in the future. Does that need to be retroactive?
> This is particularly annoying, since sparc-solaris2.9 is one of the platforms > on which I regtested this patch! Either you have a C99-aware version of Solaris 9 or another libgfortran is picked up at link-time. Do you HAVE_COPYSIGNF HAVE_NEXTAFTERF in config.h? > Other than that, I concur in diagnosis and solution. Will implement that as > soon as possible (most probably on Wednesday evening, European time). Thanks in advance. > Sorry, I didn't know that rule. It's not really a rule, but that would have saved me a few minutes looking for an email address accepted by Bugzilla (I successfully tried @ens.fr then @gnu.gcc.org then @gmail.com) > Will use my gcc.gnu.org address in changelogs in the future. @ens.fr is just fine I'd say (and we're exactly 2 with .fr address so... :-) as long as you can be CCed in Bugzilla. > Does that need to be retroactive? No, don't bother about that.
Subject: Re: [4.1 regression] Missing symbols "ebotcazou at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes: | > Will use my gcc.gnu.org address in changelogs in the future. | | @ens.fr is just fine I'd say (and we're exactly 2 with .fr address | so... :-) I claim to be .fr even when it says .net :-) -- Gaby
Subject: Bug 24432 CVSROOT: /cvs/gcc Module name: gcc Changes by: fxcoudert@gcc.gnu.org 2005-10-19 08:23:43 Modified files: libgfortran : c99_protos.h ChangeLog Log message: PR libfortran/24432 * c99_protos.h: Define HAVE_ macros for all provided functions. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/c99_protos.h.diff?cvsroot=gcc&r1=1.8&r2=1.9 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcc&r1=1.326&r2=1.327
Eric, I let you close this PR after you check that the regression disappeared.
> Eric, I let you close this PR after you check that the regression disappeared. Hum, now it doesn't even build: /opt/build/eric/gcc/./gcc/xgcc -B/opt/build/eric/gcc/./gcc/ -B/opt/build/eric/local/gcc/sparc-sun-solaris2.7/bin/ -B/opt/build/eric/local/gcc/sparc-sun-solaris2.7/lib/ -isystem /opt/build/eric/local/gcc/sparc-sun-solaris2.7/include -isystem /opt/build/eric/local/gcc/sparc-sun-solaris2.7/sys-include -DHAVE_CONFIG_H -I.-I/home/eric/cvs/gcc/libgfortran -I. -iquote/home/eric/cvs/gcc/libgfortran/io -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -O2 -g -c /home/eric/cvs/gcc/libgfortran/intrinsics/hyper.c -fPIC -DPIC -o .libs/hyper.o /home/eric/cvs/gcc/libgfortran/intrinsics/hyper.c:34:31: error: operator '!' has no right operand /home/eric/cvs/gcc/libgfortran/intrinsics/hyper.c:42:31: error: operator '!' has no right operand /home/eric/cvs/gcc/libgfortran/intrinsics/hyper.c:50:31: error: operator '!' has no right operand gmake[2]: *** [hyper.lo] Error 1 gmake[2]: Leaving directory `/opt/build/eric/gcc/sparc-sun-solaris2.7/libgfortran' gmake[1]: *** [all] Error 2 gmake[1]: Leaving directory `/opt/build/eric/gcc/sparc-sun-solaris2.7/libgfortran' gmake: *** [all-target-libgfortran] Error 2 Looks like you have to unify your preprocessor macro strategy in libgfortran.
Subject: Bug 24432 CVSROOT: /cvs/gcc Module name: gcc Changes by: fxcoudert@gcc.gnu.org 2005-10-19 09:45:27 Modified files: libgfortran : c99_protos.h ChangeLog libgfortran/intrinsics: c99_functions.c getXid.c sleep.c Log message: PR libfortran/24432 * c99_protos.h: Define preprocessor HAVE_ macros with value 1 instead of empty value. * intrinsics/c99_functions.c: Likewise. * intrinsics/getXid.c: Define HAVE_GETPID with value 1 instead of empty value. * intrinsics/sleep.c: Define HAVE_SLEEP with value 1 instead of empty value. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/c99_protos.h.diff?cvsroot=gcc&r1=1.9&r2=1.10 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcc&r1=1.327&r2=1.328 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/intrinsics/c99_functions.c.diff?cvsroot=gcc&r1=1.17&r2=1.18 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/intrinsics/getXid.c.diff?cvsroot=gcc&r1=1.5&r2=1.6 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/intrinsics/sleep.c.diff?cvsroot=gcc&r1=1.3&r2=1.4
(In reply to comment #7) > Looks like you have to unify your preprocessor macro strategy in libgfortran. Oh, s***. Now, they're defined with value 1 (unless my grep failed me, I think I've done them all).
Much better, only 8 remaining failures: Running /home/eric/cvs/gcc/gcc/testsuite/gfortran.dg/dg.exp ... FAIL: gfortran.dg/large_real_kind_2.F90 -O0 (test for excess errors) WARNING: gfortran.dg/large_real_kind_2.F90 -O0 compilation failed to produce executable FAIL: gfortran.dg/large_real_kind_2.F90 -O1 (test for excess errors) WARNING: gfortran.dg/large_real_kind_2.F90 -O1 compilation failed to produce executable FAIL: gfortran.dg/large_real_kind_2.F90 -O2 (test for excess errors) WARNING: gfortran.dg/large_real_kind_2.F90 -O2 compilation failed to produce executable FAIL: gfortran.dg/large_real_kind_2.F90 -O3 -fomit-frame-pointer (test for excess errors) WARNING: gfortran.dg/large_real_kind_2.F90 -O3 -fomit-frame-pointer compilation failed to produce executable FAIL: gfortran.dg/large_real_kind_2.F90 -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) WARNING: gfortran.dg/large_real_kind_2.F90 -O3 -fomit-frame-pointer -funroll-loops compilation failed to produce executable FAIL: gfortran.dg/large_real_kind_2.F90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) WARNING: gfortran.dg/large_real_kind_2.F90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions compilation failed to produce executable FAIL: gfortran.dg/large_real_kind_2.F90 -O3 -g (test for excess errors) WARNING: gfortran.dg/large_real_kind_2.F90 -O3 -g compilation failed to produce executable FAIL: gfortran.dg/large_real_kind_2.F90 -Os (test for excess errors) WARNING: gfortran.dg/large_real_kind_2.F90 -Os compilation failed to produce executable Undefined first referenced^M symbol in file^M cexpl /var/tmp//ccDZzOIe.o^M ccosl /var/tmp//ccDZzOIe.o^M csqrtl /var/tmp//ccDZzOIe.o^M asinhl /var/tmp//ccDZzOIe.o^M expl /var/tmp//ccDZzOIe.o^M cosl /var/tmp//ccDZzOIe.o^M erfcl /var/tmp//ccDZzOIe.o^M cpowl /var/tmp//ccDZzOIe.o^M csinl /var/tmp//ccDZzOIe.o^M sqrtl /var/tmp//ccDZzOIe.o^M coshl /var/tmp//ccDZzOIe.o^M sinl /var/tmp//ccDZzOIe.o^M atanhl /var/tmp//ccDZzOIe.o^M clogl /var/tmp//ccDZzOIe.o^M atanl /var/tmp//ccDZzOIe.o^M logl /var/tmp//ccDZzOIe.o^M sinhl /var/tmp//ccDZzOIe.o^M erfl /var/tmp//ccDZzOIe.o^M acosl /var/tmp//ccDZzOIe.o^M cabsl /var/tmp//ccDZzOIe.o^M acoshl /var/tmp//ccDZzOIe.o^M tanhl /var/tmp//ccDZzOIe.o^M tanl /var/tmp//ccDZzOIe.o^M asinl /var/tmp//ccDZzOIe.o^M However I see that large_real_kind_2.F90 was added alongside the patch. What's the correct approach to fixing that? Enhancing again c99_functions?
(In reply to comment #10) > Running /home/eric/cvs/gcc/gcc/testsuite/gfortran.dg/dg.exp ... > FAIL: gfortran.dg/large_real_kind_2.F90 -O0 (test for excess errors) > WARNING: gfortran.dg/large_real_kind_2.F90 -O0 compilation failed to produce > executable > However I see that large_real_kind_2.F90 was added alongside the > patch. What's > the correct approach to fixing that? Enhancing again c99_functions? The only fix that I've found is to delete the code up to the last line "end". Apparently, dejagnu will not xfail a *.F90 file that needs to go through the preprocessor.
> The only fix that I've found is to delete the code up to the > last line "end". Apparently, dejagnu will not xfail a *.F90 file > that needs to go through the preprocessor. Is it really XFAILed on non-C99 SPARC/Solaris? It passes on SPARC/Solaris 10, which is C99.
FreeBSD has the same problem with missing long double math functions. I tried to add an appropriate XFAIL clause for FreeBSD, but dejagnu would still process the file. I'm working on some of the FreeBSD libm issues, which has severely limited my gfortran hacking. At the momemnt, we should probably find a way to add { target *-*-linux } to the file. I'm guessing that dejagnu's tcl scripts need to be taught about the .F, .F90, and .F95 suffixes.
> FreeBSD has the same problem with missing long double math > functions. I tried to add an appropriate XFAIL clause for > FreeBSD, but dejagnu would still process the file. I'm > working on some of the FreeBSD libm issues, which has > severely limited my gfortran hacking. At the momemnt, we > should probably find a way to add { target *-*-linux } > to the file. I'm guessing that dejagnu's tcl scripts need > to be taught about the .F, .F90, and .F95 suffixes. OK, thanks for your efforts. I'm closing this PR.
> FreeBSD has the same problem with missing long double math > functions. I tried to add an appropriate XFAIL clause for > FreeBSD, but dejagnu would still process the file. Huh... the following patch fixes the problem for me. Can I install it? Index: lib/target-supports.exp =================================================================== --- lib/target-supports.exp (revision 107161) +++ lib/target-supports.exp (working copy) @@ -530,6 +530,7 @@ puts $f "integer,parameter :: k = &" puts $f " selected_real_kind (precision (0.0_8) + 1)" puts $f "real(kind=k) :: x" + puts $f "x = cos (x);" puts $f "end" close $f
(In reply to comment #15) > Huh... the following patch fixes the problem for me. Can I install it? Fine with me. Consider approved after testing on some C99-aware platform (like solaris2.10). Please commit on 4.1 as well as mainline.
> Fine with me. Consider approved after testing on some C99-aware platform (like > solaris2.10) Thanks. My main machine is actually x86-64/Linux so I've verified there that the large real tests are still reported as executed in testsuite/gfortran.log. Same on the Solaris 10 machine. > Please commit on 4.1 as well as mainline. Will do.
Subject: Bug 24432 Author: ebotcazou Date: Mon Nov 21 20:52:25 2005 New Revision: 107321 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107321 Log: PR libfortran/24432 * lib/target-supports.exp (check_effective_target_fortran_large_real): Check that 'cos' is supported. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/lib/target-supports.exp
Subject: Bug 24432 Author: ebotcazou Date: Mon Nov 21 20:53:50 2005 New Revision: 107323 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=107323 Log: PR libfortran/24432 * lib/target-supports.exp (check_effective_target_fortran_large_real): Check that 'cos' is supported. Modified: branches/gcc-4_1-branch/gcc/testsuite/ChangeLog branches/gcc-4_1-branch/gcc/testsuite/lib/target-supports.exp