I suppose mainline is affected as well, but I've first got a report about this and tested on GCC 4.4.2. Bootstrapping GCC 4.4.2 on Solaris 11/SPARC and Solaris 10/x86 with Sun Studio 12.1 fails in stage 1 linking xgcc: Undefined first referenced symbol in file __gmpn_perfect_square_p gcc.o __gmpz_tdiv_q gcc.o __gmpq_set gcc.o __gmpz_set gcc.o __gmpn_add_n gcc.o __gmpn_sub_n gcc.o __gmpn_popcount gcc.o ld: fatal: Symbol referencing errors. No output written to xgcc Re-running the gcc.o build with -E reveals that e.g. the reference to __gmpn_perfect_square_p is from __gmpz_perfect_square_p which is *defined* as extern in the header, although __GMP_EXTERN_INLINE is correctly defined in gmp.h for __SUNPRO_C >= 0x560 (this is 0x5100 for Studio 12.1). It turned out that ansidecl.h was the culprit: the current file assumes that inline is a keyword #if __STDC_VERSION__ > 199901L which is wrong: C99 defines __STDC_VERSION__ as 199901L, so the test should be for >= instead as in several other places in GCC. But even this doesn't help: Sun cc only defines it in C99 mode (quelle surprise :-), but trying to bootstrap GCC with cc -xc99 or c99 breaks in other places (headers require e.g. -D_XOPEN_SOURCE=0x600 with c99), so I chose to use another test: #if (__STDC_VERSION__ >= 199901L) || (defined(__SUNPRO_C) && defined(__C99FEATURES__)) since the compiler supports inline even without C99 mode. This got me somewhat further, but I ran into a couple of compilation failures in the gcc directory: "/vol/src/gnu/gcc/gcc-4.4.2/gcc/bitmap.c", line 298: reference to static identifier "bitmap_elt_clear_from" in extern inline function "/vol/src/gnu/gcc/gcc-4.4.2/gcc/dominance.c", line 718: reference to static identifier "dom_convert_dir_to_idx" in extern inline function "/vol/src/gnu/gcc/gcc-4.4.2/gcc/gimple.c", line 1471: reference to static identifier "walk_gimple_asm" in extern inline function I cannot say for certain if the errors are correct, but the do make sense to me. Chaning the three functions to extern allowed to compilation to continue, but again linking xgcc failed with the same set of undefined functions. Even with extern inline, cc emits a definition of several functions in gcc.o, which still reference functions only defined in libgmp. I'm not sure what is the best way to handle this: one could link xgcc and cpp with GMPLIBS or avoid including gmp.h in headers used by gcc.c.
Created attachment 18845 [details] Patch to make inline work with Sun Studio 12.1 cc
I would prefer a solution that does not involve linking xgcc and cpp with libgmp since that links in unecessary code and/or yields a runtime penalty for loading the shared library. It's unusual that we've only just now received this report since gmp has been used since gcc-4.3 (released 1.5 years ago). So I'm curious if something more recently changed to trigger this issue. I.e. did it used to work, and some newer version of either gmp, sun cc, or solaris exposed the problem? Or did it always fail? (Also, you don't mention what version of gmp you were using.)
Subject: Re: Bootstrap with Sun Studio 12.1 fails > ------- Comment #2 from ghazi at gcc dot gnu dot org 2009-10-21 01:48 ------- > I would prefer a solution that does not involve linking xgcc and cpp with > libgmp since that links in unecessary code and/or yields a runtime penalty for > loading the shared library. Indeed, even if I've been building gmp and mpfr with --disable-shared to avoid RPATH problems. One option might be to avoid including gmp.h in gcc.c in the first place, as I've already mentioned. I'm not sure how easy that would be, though. > It's unusual that we've only just now received this report since gmp has been > used since gcc-4.3 (released 1.5 years ago). So I'm curious if something more > recently changed to trigger this issue. I.e. did it used to work, and some > newer version of either gmp, sun cc, or solaris exposed the problem? Or did it > always fail? I've never tried this before (I regularly build with GCC 3.4 as a bootstrap compiler since I want to include Ada support and that requires an Ada compiler), but only just received a report from a colleague who tried to build GCC 4.4 within pkgsrc, but failed in unexpected ways. > (Also, you don't mention what version of gmp you were using.) Right, sorry: I've tried this with the latest version, gmp 4.3.1. Rainer
Subject: Re: Bootstrap with Sun Studio 12.1 fails Just for reference: here's the corresponding pkgsrc problem report by my colleague: http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=42109 So at least bootstrapping with Studio 12 exhibits the same problem. Rainer
(In reply to comment #3) > > (Also, you don't mention what version of gmp you were using.) > Right, sorry: I've tried this with the latest version, gmp 4.3.1. Okay I checked gmp source tarballs, and it looks like the SUNPRO clauses defining __GMP_EXTERN_INLINE were added specifically in gmp-4.3.1. I don't see them in gmp-4.2.4 or gmp-4.3.0. Could you please verify bootstrapping gcc with those two versions of gmp plus Sun's cc to see if they work? If it does we should offer it as a workaround for users until we figure out how we want to solve this long-term. Recommending other versions of gmp as a workaround is helpful even if we hack up a patch to GCC, because gcc-4.3 and 4.4 will not see these "fixes" until some months in the future when we do another release. Alternatively we may end up recommending to the gmp maintainer(s) that they fix the problem in their package since that's what's really broken IMHO. Either way, it would be helpful to know whether using other versions of gmp would help. Thanks.
Subject: Re: Bootstrap with Sun Studio 12.1 fails > ------- Comment #5 from ghazi at gcc dot gnu dot org 2009-10-21 19:51 ------- > (In reply to comment #3) > > > (Also, you don't mention what version of gmp you were using.) > > Right, sorry: I've tried this with the latest version, gmp 4.3.1. > > Okay I checked gmp source tarballs, and it looks like the SUNPRO clauses > defining __GMP_EXTERN_INLINE were added specifically in gmp-4.3.1. I don't see > them in gmp-4.2.4 or gmp-4.3.0. Could you please verify bootstrapping gcc with > those two versions of gmp plus Sun's cc to see if they work? If it does we > should offer it as a workaround for users until we figure out how we want to > solve this long-term. I've only tried with gmp 4.3.0, but this works on i386-pc-solaris2.10. So for the moment, we have a workaround. > Recommending other versions of gmp as a workaround is helpful even if we hack > up a patch to GCC, because gcc-4.3 and 4.4 will not see these "fixes" until > some months in the future when we do another release. Alternatively we may end > up recommending to the gmp maintainer(s) that they fix the problem in their > package since that's what's really broken IMHO. Either way, it would be > helpful to know whether using other versions of gmp would help. I'm not sure we can claim there is GMP breakage at all: they could argue that anyone including <gmp.h> can be expected to link with -lgmp as well. I just don't know if it is correct to assume that a function defined as extern inline in a header will not be emitted in the object file. Even so, there is breakage in GCC as well: * ansidecl.h has a broken test for C99, and incorrectly assumes Sun cc doesn't support extern inline. The define from inline to nothing causes part of the problem. * Three files in the gcc directory declared extern inline call static functions, which causes Sun Studio cc to error out (cf. the attached diff). Rainer
(In reply to comment #6) > I'm not sure we can claim there is GMP breakage at all: they could argue > that anyone including <gmp.h> can be expected to link with -lgmp as well. > I just don't know if it is correct to assume that a function defined as > extern inline in a header will not be emitted in the object file. Fair enough, okay. > Even so, there is breakage in GCC as well: > * ansidecl.h has a broken test for C99, and incorrectly assumes Sun cc > doesn't support extern inline. The define from inline to nothing causes > part of the problem. > * Three files in the gcc directory declared extern inline call static > functions, which causes Sun Studio cc to error out (cf. the attached > diff). > Rainer I have no objection to these patches. However I think you said they don't actually solve the problem right? So between link xgcc with -lgmp and don't include gmp.h, I prefer the latter approach. Let's not include gmp.h in gcc.c (and anywhere else it isn't necessary.) Say I have a silly question, how is gmp.h getting pulled into gcc.c in the first place? It's supposed to come in via real.h which should only get included by middle-end files linking with real.o ... If we can't disentangle real.h from this then another approach would be to define GENERATOR_FILE (or likely some new macro name) and avoid including the problematic headers that way. Then -D this macro in the gcc.o rule in the Makefile.
Subject: Re: Bootstrap with Sun Studio 12.1 fails > > Even so, there is breakage in GCC as well: > > * ansidecl.h has a broken test for C99, and incorrectly assumes Sun cc > > doesn't support extern inline. The define from inline to nothing causes > > part of the problem. > > * Three files in the gcc directory declared extern inline call static > > functions, which causes Sun Studio cc to error out (cf. the attached > > diff). > I have no objection to these patches. However I think you said they don't > actually solve the problem right? They are necessary if you fix ansidecl.h to properly handle non-GCC C99 compilers and Sun Studio cc. I have no idea if the Sun compiler is right to error out here, though: that's probably for the reviewer to decide. The other problem is if compilers are allowed to emit code for extern inline functions that are unused: if so, the patches above are not enough and we need to fix either GCC or GMP (unless they argue that it's wrong to include gmp.h, but not to link with -lgmp). > So between link xgcc with -lgmp and don't include gmp.h, I prefer the latter > approach. Let's not include gmp.h in gcc.c (and anywhere else it isn't > necessary.) Fully agreed: linking with -lgmp is just a hack. > Say I have a silly question, how is gmp.h getting pulled into gcc.c in the > first place? It's supposed to come in via real.h which should only get > included by middle-end files linking with real.o ... > > If we can't disentangle real.h from this then another approach would be to > define GENERATOR_FILE (or likely some new macro name) and avoid including the > problematic headers that way. Then -D this macro in the gcc.o rule in the > Makefile. Seems like a good approach to me. Rainer
(In reply to comment #8) > > Say I have a silly question, how is gmp.h getting pulled into gcc.c in the > > first place? It's supposed to come in via real.h which should only get > > included by middle-end files linking with real.o ... So the sequence is gcc.c includes flags.h which includes real.h. That last include was introduced by this patch: http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00716.html IMHO, flags.h should not include real.h if things like gcc.c will include it and not link against real.o and -lgmp etc. But I don't know which if any targets now depend on this include. I tried x86_64-linux-gnu and I was able to link xgcc and cc1. But some other target may have a problem. Perhaps Ulrich can explain why he chose to add that include so we can see if there's another way to accomplish the goal.
(In reply to comment #9) > IMHO, flags.h should not include real.h if things like gcc.c will include it > and not link against real.o and -lgmp etc. But I don't know which if any > targets now depend on this include. I tried x86_64-linux-gnu and I was able to > link xgcc and cc1. But some other target may have a problem. > > Perhaps Ulrich can explain why he chose to add that include so we can see if > there's another way to accomplish the goal. flags.h contains macros like HONOR_NANS which are defined in terms of macros like MODE_HAS_NANS. The MODE_HAS_... macros used to be defined in target headers (or defaults.h) before my patch. That patch changed the MODE_HAS_... macros to be defined in terms of properties of the floating-point format structure (struct real_format) instead of requiring the target to provide this information in a redundant way via special target macros. In order to be able to access struct real_format, those new MODE_HAS_... macros needed to be defined in real.h. In order to keep the definition of the HONOR_... macros in flags.h working, I added the include of real.h to flags.h. If this is problematic, I guess an alternative might be to move the HONOR_... macros from flags.h to real.h as well, and update all files that use these macros to also include real.h.
(In reply to comment #10) > If this is problematic, I guess an alternative might be to move the > HONOR_... macros from flags.h to real.h as well, and update all files > that use these macros to also include real.h. From a quick review, this seems to be pretty straightforward -- all files using the HONOR_... macros already include real.h either directly or indirectly via its inclusion in rtl.h, with the single exception of tree-ssa-reassoc.c.
Rainer, I believe this bug has been appropriatly analyzed and diagnosed. You have the affected system and can test, are you working on a fix?
Mine, fix in progress.
Subject: Re: Bootstrap with Sun Studio 12.1 fails Patch here: http://gcc.gnu.org/ml/gcc-patches/2009-12/msg00625.html.
Subject: Bug 41771 Author: ro Date: Tue Jan 5 17:14:30 2010 New Revision: 155654 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155654 Log: gcc: PR bootstrap/41771 * flags.h: Don't include real.h. (HONOR_NANS, HONOR_SNANS, HONOR_INFINITIES, HONOR_SIGNED_ZEROS, HONOR_SIGN_DEPENDENT_ROUNDING): Move ... * real.h (HONOR_NANS, HONOR_SNANS, HONOR_INFINITIES, HONOR_SIGNED_ZEROS, HONOR_SIGN_DEPENDENT_ROUNDING): ... here. * dominance.c: Update copyright. * gimple.c (walk_gimple_op): Remove inline. * tree-ssa-reassoc.c: Include real.h. * Makefile.in (FLAGS_H): Remove $(REAL_H). (tree-ssa-reassoc.o): Depend on $(REAL_H). include: PR bootstrap/41771 * ansidecl.h: Fix inline test for C99 and Sun Studio cc. Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/dominance.c trunk/gcc/flags.h trunk/gcc/gimple.c trunk/gcc/real.h trunk/gcc/tree-ssa-reassoc.c trunk/include/ChangeLog trunk/include/ansidecl.h
Fixed for 4.5.0.