On Tue, 11 Dec 2012, Aldy Hernandez wrote: > Hi Richard. > > Your last patch for this PR suggested we verify our assumptions wrt a least > common C++ compiler to build trunk with. Since I already had the offended > system at hand (Red Hat Linux 8.0), I decided to investigate a bit further. > > g++ 3.4 builds trunk just fine, but anything prior to this chokes on a variety > of inputs. The patch below fixes them all, and gets 4.8 to bootstrap with a > GCC 3.2 system. > > I don't know how much of this is a fool's errand, and if we want to commit to > supporting < GCC 3.4, but your patch suggested c++98, and GCC 3.2 claims such. > > The fixed issues are as follows: > > 1. Older G++ cannot understand attributes among arguments: > > int foo(int bar __attribute__ ((__unused__))) > > It looks like we already have ARG_UNUSED for this precise problem, > and it is already predicated on !__cplusplus || GCC_VERSION >= 3004. > However, we've deviated from using ARG_UNUSED > throughout the compiler, and I spent hours changing > ATTRIBUTE_UNUSED into ARG_UNUSED until I gave up. It's EVERYWHERE > in the compiler-- all the way into our gen*.c files. It seemed a lot > simpler just changing the definition of ATTRIBUTE_UNUSED. > > Perhaps we could even deprecate ARG_UNUSED? > > 2. gcov-io.c uses __builtin_popcountll and __builtin_clzll. Older > GCC's do not have this. For that matter, how does this even work on > non-GCC systems? > > I have abstracted the non built-in versions we have for these in > hwint.c, which seem written for older GCC's and non GCC's. > > I am not a huge fan of the new include file, but I really didn't > want to duplicate code. I'm open to suggestions. > > 3. Derived classes that include a union template die miserably on g++ > 3.2. Thankfully, this works: > > -struct ssa_name_var_hash : typed_noop_remove <union tree_node> > +struct ssa_name_var_hash : typed_noop_remove <tree_node> > > 4. Type checking as part of a `for' initializer segfaults on g++ 3.2: > > for (type = TYPE_MAIN_VARIANT (blah); ....) > > The only reasonable thing I could think of, was disabling the tree > checking code for older compilers. > > I really don't want to spend much more time on this, but at the same time, I > don't want to throw away a day's work, especially if it could conceivably help > us with (older) non-GCC bootstrap compilers. > > The attached patch bootstraps trunk on GCC 3.2 on a Red Hat Linux 8.0 system > (i686) configured with: > > blah/configure --enable-languages=c,c++ --disable-libsanitizer > > libsanitizer seems to be a moving target and it currently has issues with the > RHL8.0 header files (earlier today it had other problems :)). > > What are your thoughts on this?
In general I think that trying to support anything before the C++ parser rewrite (thus, 3.4.x) is going to be a nightmare ... But of course as you show it _is_ possible at the moment at least. Patches for 1. and 3. I'd call obvious. For 3. I wonder why we ever build gcov-io with the host compiler - oh, we include it from coverage.c ... please file a bug for this, the uses were introduced recently by Theresa Johnson from google, that's of course a release blocker anyway. For 4. I think we should simply document that you need to build with --disable-stage1-checking (it's one case that hints at we don't want to support 3.2 - does 3.3 work here? With our SLE9 gcc 3.3 hammer branch based compiler I get even some more ICEs). Thanks, Richard.
