Bootstrapping the current tree-ssa branch with gmp 4.1.3 (and thus gfortran enabled) on Tru64 UNIX V5.1B fails compiling libgfortran/runtime/environ.c: In file included from /vol/gnu/src/gcc/gcc-tree-ssa-dist/libgfortran/runtime/environ.c:26: /vol/gnu/src/gcc/gcc-tree-ssa-dist/libgfortran/libgfortran.h:75: error: parse error before "GFC_INTEGER_4" This happens because there is no definition of int32_t and similar types anywhere. While there is one in <inttypes.h> and there's even a configure test for that header, it isn't used anywere. Obviously, libgfortran needs to make sure that a definition of those types is available at configure time and provide one itself if not. While a trivial patch to use that file in libgfortran.h gets me a little bit further, I immediately hit another error: /vol/gnu/src/gcc/gcc-tree-ssa-dist/libgfortran/runtime/../io/io.h:282: error: conflicting types for 'unit_t' /vol/gcc/obj/gcc-3.5-tree-ssa-20040429/5.1b-gcc/gcc/include/sys/types.h:595: error: previous declaration of 'unit_t' was here In fact, AFAIK the *_t types are reserved by POSIX.1 and thus cannot be used without risk of conflict. Environment: System: OSF1 bartok V5.1 2650 alpha Machine: alpha host: alpha-dec-osf5.1b build: alpha-dec-osf5.1b target: alpha-dec-osf5.1b configured with: /vol/gnu/src/gcc/gcc-tree-ssa-dist/configure --prefix=/vol/gcc --with-local-prefix=/vol/gcc --disable-nls --host alpha-dec-osf5.1b --build alpha-dec-osf5.1b --target alpha-dec-osf5.1b --disable-libmudflap --with-gmp-dir=/vol/gnu/obj/gmp-4.1.3 How-To-Repeat: Try bootstrapping the tree-ssa branch on Tru64 UNIX V5.1B with gmp.
Fix: Fri Apr 30 21:01:32 2004 Rainer Orth <ro@TechFak.Uni-Bielefeld.DE> * libgfortran.h [HAVE_INTTYPES_H]: Include <inttypes.h> if available. Index: libgfortran.h =================================================================== RCS file: /vol/gnu/src/gcc/.gcc-cvs/gcc/libgfortran/Attic/libgfortran.h,v retrieving revision 1.1.2.7 diff -u -p -r1.1.2.7 libgfortran.h --- libgfortran.h 30 Nov 2003 17:24:21 -0000 1.1.2.7 +++ libgfortran.h 30 Apr 2004 18:55:47 -0000 @@ -43,6 +43,10 @@ Boston, MA 02111-1307, USA. */ #include <stdint.h> #endif +#if HAVE_INTTYPES_H +#include <inttypes.h> +#endif + #if HAVE_SYS_TYPES_H #include <sys/types.h> #endif
Confirmed.
Subject: Bug 15234 CVSROOT: /cvs/gcc Module name: gcc Branch: tree-ssa-20020619-branch Changes by: steven@gcc.gnu.org 2004-05-07 09:02:49 Modified files: libgfortran : ChangeLog libgfortran.h Log message: PR libfortran/15234 * libgfortran.h: Include <inttypes.h> if available. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcc&only_with_tag=tree-ssa-20020619-branch&r1=1.1.2.49&r2=1.1.2.50 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/libgfortran.h.diff?cvsroot=gcc&only_with_tag=tree-ssa-20020619-branch&r1=1.1.2.7&r2=1.1.2.8
Should be fixed now.
Rainer, the unit_t thing is for post-merge.
Subject: Re: [tree-ssa] libgfortran doesn't compile on Tru64 UNIX steven at gcc dot gnu dot org writes: > Rainer, the unit_t thing is for post-merge. Ok, but in this case the PR should remain open since this is its main issue. (I cannot do this right now since gcc.gnu.org isn't reachable.) Maybe one can solve this once and for all by a mechanical renaming of the affected types from <something>_t to gfc_<something>_t? Rainer
Subject: Re: [tree-ssa] libgfortran doesn't compile on Tru64 UNIX steven at gcc dot gnu dot org writes: > Should be fixed now. The <inttypes.h> part is indeed, thanks. Rainer
Primariy problem (unit_t conflict with system headers) not fixed yet.
Patch here: http://gcc.gnu.org/ml/fortran/2004-05/msg00158.html
Subject: Bug 15234 CVSROOT: /cvs/gcc Module name: gcc Changes by: tobi@gcc.gnu.org 2004-05-15 20:44:38 Modified files: libgfortran : ChangeLog libgfortran/io : backspace.c close.c endfile.c inquire.c io.h open.c rewind.c transfer.c unit.c unix.c Log message: PR fortran/15234 * io/io.h (unit_t): Rename to ... (gfc_unit) ... this. (unit_root, current_unit, find_file, find_unit, get_unit): Now of type gfc_unit. (delete_file, insert_unit, close_unit): Argument now of type gfc_unit. * backspace.c (st_backspace), close.c (st_close), endfile.c (st_endfile), inquire.c (inquire_via_unit, st_inquire), open.c (test_endfile, edit_modes, new_unit, already_open, st_open), rewind.c (st_rewind), transfer.c (current_unit), unit.c (internal_unit, unit_cache, rotate_left, rotate_right, insert, insert_unit, delete_root, delete_treap, delete_unit, find_unit, get_unit, init_units, close_unit), unix.c (find_file0, find_file, delete_file): Replace all occurences of unit_t by gfc_unit. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcc&r1=1.7&r2=1.8 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/backspace.c.diff?cvsroot=gcc&r1=1.2&r2=1.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/close.c.diff?cvsroot=gcc&r1=1.2&r2=1.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/endfile.c.diff?cvsroot=gcc&r1=1.2&r2=1.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/inquire.c.diff?cvsroot=gcc&r1=1.2&r2=1.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/io.h.diff?cvsroot=gcc&r1=1.2&r2=1.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/open.c.diff?cvsroot=gcc&r1=1.2&r2=1.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/rewind.c.diff?cvsroot=gcc&r1=1.2&r2=1.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/transfer.c.diff?cvsroot=gcc&r1=1.2&r2=1.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/unit.c.diff?cvsroot=gcc&r1=1.2&r2=1.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/io/unix.c.diff?cvsroot=gcc&r1=1.2&r2=1.3
Can you please verify that your problem is fixed, Rainer? Danke.
Subject: Re: [gfortran] libgfortran doesn't compile on Tru64 UNIX tobi at gcc dot gnu dot org writes: > Can you please verify that your problem is fixed, Rainer? Danke. Mainline bootstrap on alpha-dec-osf4.0f in progress ... Rainer
Subject: Re: [gfortran] libgfortran doesn't compile on Tru64 UNIX tobi at gcc dot gnu dot org writes: > Can you please verify that your problem is fixed, Rainer? Danke. Bootstrap on alpha-dec-osf4.0f still fails, but for the other problem originally reported in this PR: there's no definition of int64_t etc. anywhere, and (unlike Tru64 UNIX V5.1B) there's no <inttypes.h> (well, there's <db.h> for Compaq's version of Berkeley DB, but it doesn't make sense to include that header just because it happens to define the required types), so compilation still fails. I'm now running another bootstrap on alpha-dec-osf5.1b to see if at least the unit_t problem is fixed there. Rainer
Subject: Re: [gfortran] libgfortran doesn't compile on Tru64 UNIX Bootstrap on alpha-dec-osf5.1b doesn't succeed either, but this time it's a different failure: /vol/gnu/src/gcc/gcc-dist/libgfortran/intrinsics/associated.c:26: error: parse error before numeric constant This happens because <sys/types.h> has #define TRUE 1 #define FALSE 0 so we get enum { 0 = 0, 1 = 1 }; But even with the obvious patch below, I run into another error: /vol/gnu/src/gcc/gcc-dist/libgfortran/generated/exp_c4.c:29: error: conflicting types for 'cabsf' /vol/gcc/obj/gcc-3.5.0-20040517/5.1b-gcc/gcc/include/math.h:315: error: previous declaration of 'cabsf' was here make[3]: *** [exp_c4.lo] Error 1 I.e. GFC_REAL_4 cabsf (GFC_COMPLEX_4 z); vs. extern float cabsf ( float, float ); This is similar to PR libfortran/15266, which isn't fixed yet, either. Rainer Mon May 17 20:56:21 2004 Rainer Orth <ro@TechFak.Uni-Bielefeld.DE> * intrinsics/associated.c: Renamed FALSE, TRUE to GFC_FALSE, GFC_TRUE. Index: intrinsics/associated.c =================================================================== RCS file: /cvs/gcc/gcc/libgfortran/intrinsics/associated.c,v retrieving revision 1.2 diff -u -p -r1.2 associated.c --- intrinsics/associated.c 13 May 2004 06:41:02 -0000 1.2 +++ intrinsics/associated.c 17 May 2004 18:59:06 -0000 @@ -23,7 +23,7 @@ Boston, MA 02111-1307, USA. */ #define associated prefix(associated) -enum { FALSE = 0, TRUE = 1 }; +enum { GFC_FALSE = 0, GFC_TRUE = 1 }; GFC_LOGICAL_4 @@ -32,19 +32,19 @@ associated (const gfc_array_void *pointe int n, rank; if (GFC_DESCRIPTOR_DATA (pointer) != GFC_DESCRIPTOR_DATA (target)) - return FALSE; + return GFC_FALSE; if (GFC_DESCRIPTOR_DTYPE (pointer) != GFC_DESCRIPTOR_DTYPE (target)) - return FALSE; + return GFC_FALSE; rank = GFC_DESCRIPTOR_RANK (pointer); for (n = 0; n < rank; n++) { if (pointer->dim[n].stride != target->dim[n].stride) - return FALSE; + return GFC_FALSE; if ((pointer->dim[n].ubound - pointer->dim[n].lbound) != (target->dim[n].ubound - target->dim[n].lbound)) - return FALSE; + return GFC_FALSE; } - return TRUE; + return GFC_TRUE; }
Yes and IIRC when Tru64 (if ever) gets C99 most of everyone's code gets broken if they used csqrtf.
Subject: Re: [gfortran] libgfortran doesn't compile on Tru64 UNIX pinskia at gcc dot gnu dot org writes: > Yes and IIRC when Tru64 (if ever) gets C99 most of everyone's code gets broken if they used csqrtf. As in the SGI/IRIX case, Compaq/HP has already demonstrated that they know how to deal with source and binary compatility and have mechanisms in place (see #pragma extern_prefix) that support this. Rainer
(In reply to comment #14) > Subject: Re: [gfortran] libgfortran doesn't compile on Tru64 UNIX > > Bootstrap on alpha-dec-osf5.1b doesn't succeed either, but this time it's a > different failure: > > /vol/gnu/src/gcc/gcc-dist/libgfortran/intrinsics/associated.c:26: error: parse error before numeric constant > > This happens because <sys/types.h> has > > #define TRUE 1 > #define FALSE 0 > > so we get > > enum { 0 = 0, 1 = 1 }; > I think we can just do away with that enum, in all other places gfortran uses 0 and 1 for true and false. I will submit a patch to that effect. Doing the right thing with respect to those c* library functions requires a better knowledge of portability issues and how the compiler interacts with the library than I have. I'm changing this bug's status back to new.
Subject: Bug 15234 CVSROOT: /cvs/gcc Module name: gcc Changes by: tobi@gcc.gnu.org 2004-05-27 13:05:23 Modified files: libgfortran : ChangeLog libgfortran/intrinsics: associated.c Log message: PR fortran/15234 * intrinsics/associated.c: Remove enum. (associated): Replace TRUE/FALSE by 1/0. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/ChangeLog.diff?cvsroot=gcc&r1=1.19&r2=1.20 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libgfortran/intrinsics/associated.c.diff?cvsroot=gcc&r1=1.2&r2=1.3
Subject: Bug 15234 CVSROOT: /cvs/gcc Module name: gcc Changes by: tobi@gcc.gnu.org 2004-07-15 14:53:29 Modified files: gcc/fortran : ChangeLog trans-array.c Log message: PR fortran/15234 * trans-array.c gfc_trans_g77_array, gfc_trans_dummy_array_bias): Don't call gfc_trans_string_init for assumed length characters. (gfc_conv_expr_descriptor): Set se->string_length if dealing with a character expression. (gfc_cvonv_array_parameter): Pass string length when passing character array according to g77 conventions. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&r1=1.125&r2=1.126 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/trans-array.c.diff?cvsroot=gcc&r1=1.10&r2=1.11
(In reply to comment #19) > Subject: Bug 15234 > > CVSROOT: /cvs/gcc > Module name: gcc > Changes by: tobi@gcc.gnu.org 2004-07-15 14:53:29 Sorry, wrong PR
You can close it as a dup of bug 14325 (if you want) as it is GCC's job to provide a stdint.h anyways (which is PR 448).
gcc-4.0 including gfortran build fine on Tru64 OSF1 V5.1 2650 alpha as long as gcc and GNU make are used in the build. I built GNU Fortran 95 (GCC 4.0.0 20041114 (experimental)) with gcc-3.3.2 (TWW). It gives no trouble at all, as long as LD_LIBRARY_PATH points to the gcc libraries and to gmp/mpfr.
5.1 is fixed but 4.0 is still broken.
This is __NOT__ fixed by (because alpha is a LP64 target) but it makes it easier to fix: * acinclude.m4 (LIBGFOR_TARGET_ILP32): New check. * configure.ac: Include LIBGFOR_TARGET_ILP32. * configure: Regenerate. * config.h.in: Likewise. * libgfortran.h: Provide default definitions for C99 types on ILP32 targets that don't have them.
I don't consider this a regression; libgfortran is new in this release. So, I have removed the target milestone.
As I learnt from PR21950, there is a (recent) patch for this one. For the record: http://gcc.gnu.org/ml/fortran/2005-06/msg00118.html
Do we need to keep this one open? Isn't it fixed the patch for PR21950?
Any news?
Subject: Re: libgfortran doesn't compile on Tru64 UNIX V4.0F tobi at gcc dot gnu dot org writes: > Any news? Sorry for the delay: I've been ill for several weeks and am still catching up on my mail. My patch for this problem http://gcc.gnu.org/ml/fortran/2005-06/msg00118.html is still required. I'll address the comments raised on the mailing lists, but since they all suggest possible cleanups to the way LIBGFOR_TARGET_ILP32 (and now LIBGFOR_TARGET_LP64) are implemented, I'd prefer my patch to go in unchanged (as it matches existing practice) and possibly implement cleanups as followups if deemed worthwhile. Rainer
(In reply to comment #29) > I'll address the comments raised on the mailing lists, > but since they all suggest possible cleanups to the way > LIBGFOR_TARGET_ILP32 (and now LIBGFOR_TARGET_LP64) are implemented, I'd > prefer my patch to go in unchanged (as it matches existing practice) and > possibly implement cleanups as followups if deemed worthwhile. I do agree with you. Can you re-submit the patch on the fortran ml for approval?
(In reply to comment #30) > Can you re-submit the patch on the fortran ml for approval? ping
*** Bug 24391 has been marked as a duplicate of this bug. ***
(In reply to comment #30) > I do agree with you. Can you re-submit the patch on the fortran ml for approval? ping*2
The only patch left is http://gcc.gnu.org/ml/gcc-patches/2005-12/msg01578.html The rest was fixed by the patch which fixed PR 25259 which added a stdint.h to include.
Fixed by: 2006-01-16 Roger Sayle <roger@eyesopen.com> * configure.ac (CFLAGS): Update to include -std=gnu99 so that the configure tests will be run with the same environment as used to compile the libgfortran source code. * configure: Regenerate. 2006-01-12 Roger Sayle <roger@eyesopen.com> * intrinsics/c99_functions.c: Add function prototypes to avoid warnings from -Wstrict-prototypes -Wmissing-prototypes. On Tru64 work around a brain-dead libm by redirecting calls to cabs{,f,l} to a local __gfc_cabs{,f,l}.
Subject: Bug 15234 Author: ro Date: Tue Feb 14 17:28:02 2006 New Revision: 110988 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110988 Log: PR libfortran/15234: Backport from mainline config: 2006-01-02 Paolo Bonzini <bonzini@gnu.org> PR target/25259 * stdint.m4: New. libgfortran: 2006-01-02 Paolo Bonzini <bonzini@gnu.org> PR target/25259 * configure.ac: Use GCC_HEADER_STDINT. * libgfortran.h: Include gstdint.h. * aclocal.m4: Regenerate. * configure: Regenerate. Added: branches/gcc-4_1-branch/config/stdint.m4 - copied unchanged from r109241, trunk/config/stdint.m4 Modified: branches/gcc-4_1-branch/config/ChangeLog branches/gcc-4_1-branch/libgfortran/ChangeLog branches/gcc-4_1-branch/libgfortran/aclocal.m4 branches/gcc-4_1-branch/libgfortran/configure branches/gcc-4_1-branch/libgfortran/configure.ac branches/gcc-4_1-branch/libgfortran/libgfortran.h
Still open on the 4.0 branch.
Subject: Bug 15234 Author: ro Date: Tue Feb 14 17:51:41 2006 New Revision: 110991 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=110991 Log: PR libfortran/15234: Backport from mainline config: 2006-01-02 Paolo Bonzini <bonzini@gnu.org> PR target/25259 * stdint.m4: New. libgfortran: 2006-01-02 Paolo Bonzini <bonzini@gnu.org> PR target/25259 * configure.ac: Use GCC_HEADER_STDINT. * libgfortran.h: Include gstdint.h. * aclocal.m4: Regenerate. * configure: Regenerate. Added: branches/gcc-4_0-branch/config/stdint.m4 - copied unchanged from r109241, trunk/config/stdint.m4 Modified: branches/gcc-4_0-branch/config/ChangeLog branches/gcc-4_0-branch/libgfortran/ChangeLog branches/gcc-4_0-branch/libgfortran/aclocal.m4 branches/gcc-4_0-branch/libgfortran/configure branches/gcc-4_0-branch/libgfortran/configure.ac branches/gcc-4_0-branch/libgfortran/libgfortran.h
Fixed for 4.0.3, too.