fold-const.c gives grief to (at least) bootstrap compilers (including older gcc) (hppa64-hpux)

[Jay <jay dot krell at cornell dot edu>]

This is more of a bug report or suggestion than a patch, and maybe not even that.
I post to gcc-help because I'm lazy, I fixed my problem, maybe someone
else can follow up further.
 
 
This on HP-UX 11iv1 (11.11) using GNU as 2.19.1.
 

gcc64 -c   -fkeep-inline-functions -DIN_GCC   -W -Wall -Wwrite-strings -Wstrict-
prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribut
e -fno-common   -DHAVE_CONFIG_H -I. -I. -I/src/gcc-4.3.3/gcc -I/src/gcc-4.3.3/gc
c/. -I/src/gcc-4.3.3/gcc/../include -I/src/gcc-4.3.3/gcc/../libcpp/include  -I/s
rc/gcc-4.3.3/gcc/../libdecnumber -I/src/gcc-4.3.3/gcc/../libdecnumber/dpd -I../l
ibdecnumber    /src/gcc-4.3.3/gcc/fold-const.c -o fold-const.o
/var/tmp//ccsPPoj7.s: Assembler messages:
/var/tmp//ccsPPoj7.s:131162: Error: Field out of range [-262144..262143] (287504).
/var/tmp//ccsPPoj7.s:131164: Error: Field out of range [-262144..262143] (288068).
/var/tmp//ccsPPoj7.s:131166: Error: Field out of range [-262144..262143] (288060).
/var/tmp//ccsPPoj7.s:131168: Error: Field out of range [-262144..262143] (288052

 
-bash-3.2$ gcc64 -v
Reading specs from /usr/local/64/lib/gcc/hppa64-hp-hpux11.11/3.4.6/specs
Configured with: /src/gcc-3.4.6/configure -disable-bootstrap -disable-nls -verbo
se -prefix=/usr/local/64 -with-as=/usr/local/64/bin/gas -with-gnu-as
Thread model: single
gcc version 3.4.6  <<< arguably the problem is here
 

This does not occur with 32bit, only 64 bit.  (I'm pretty sure I munged 32bit the same as mentioned below).
It occurs with 4.3.3 and maybe also 4.0.4. I haven't tried anythin in between,
I'm trying just to get up to 4.3.3.
 

While still "just getting things to work", I remove -g and -O2 to speed up building.
   I run configure, then edit the Makefiles, then gmake.
   Arguably also the problem. Yes, I understand. 
   But -O2 can be quite slow, -g presumably adds a lot more I/O.
Once I get things working, I'll probably rebuild.
Yes, I realize, what works vs. what I do afterward are different, so might fail afterward.
 

Putting back -O2 fixes this.
This file takes an /incredibly/ long time to compile, with -O2.
   Yeah, with the old gcc 3.4.6, itself possibly not optimized.
I have multiple things going at the same time and it is an older/slower machine,
so this is highly unscientific,
but for example all of Python built while this one file was being compiled,
and large tarballs such as binutils 2.19.1 extracted.

 
I have not investigated further, what the assembly is optimized vs. unoptimized.
 

The assembler is GNU as 2.19.1, albeit built with the old gcc 3.3.6, itself
built with the bundled K&R compiler (as documented on the gcc web pages,
as what you need to go to get these systems up.)
 

 
Anyway, I guess the stretch argument is that fold-const.c should be written
to be more portable to be compilable by more compilers.
Breaking up large functions, whatever.
 

Or maybe, and I've said things like this before I think (maybe I didn't send it?),
there could be like:
 

void big_huge_optimizing_function_that_stress_compiler(tree* t)
{
#ifdef BOOSTRAP
  /* do nothing, it is correct, albeit not optimized */
#else
  /* do a bunch of analysis/transform on t */
#endif
}
 

There are some instances on Irix where this pattern helps, using the bundled compiler..
there is apparently no documented bundled compiler, but if you search around
the file system you find a viable one easily enough..
I'm off Irix for now (weeks/months) but can report these much later.
 
 
I really like that particular suggestion, of removing entire swaths of "optional" code when building with other than current gcc. Esp. if user does not configure -disable-bootstrap -- so you know you probably will come back around and recompile it "properly". (I personally do use -disable-bootstrap frequently, so maybe the check should be for gcc and particular versions of it????)
 
 
After compiling fold-const.c optimized, I reremoved O2 from gcc/Makefile and the gcc directory successfully builds. Now to go back to toplevel (libstd++, etc.).

 
 - Jay