configure flag request

[Robert Schweikert <rjschwei at mindspring dot com>]

There are a number of people having problems building gcc-2.95.2 on
RedHat 6.2 with 2.91.66 or other versions of gcc. Well after poking
around I think I finally figured out what is going on, and I have some
proof to my theory.

The problem is related to the hardware, I am not sure who is responsible
for keeping the L2 cache clean but anyway, it ought to be some bodies
fault.

For machines using PC 100 memory it can be that the secondary cache is
too slow and it will get trashed, thus resulting in a Sig 11 during
build of gcc. Since this Sig 11 is random, depending on the current
condition of the machine etc. it can drive one nuts to try and figure
out what is going on.

Proof to the pudding is that a friend of mine had these problems, then
turned of the L2 cache and gcc build like a charm. My BIOS does not
allow me to turn of my secondary cache, thus I had to come up with
something else. Solution: I got a build log, i.e. make bootstrap >&
bld.log from another machine where the problem did not occur and then
build gcc by hand, issuing each command by cutting and pasting from the
log file to the command line. In between I every now and then go off and
do something else. This prevented the machine from getting hammered, it
took a while to get gcc compiled and installed, but at least it build
while before with the automated method it went nowhere.

In summary there are two solutions to the build problem experienced by a
number of people:

- turn of your secondary cache if you can. This of course will slow down
the machine which is undesirable.
- build by hand,  very time consuming.

To make the compile process less frustrating for some people it would be
nice if a configure flag could be added, --fastMemory for example, when
this flag is set a "wasteTime" loop would be activated in the make file.
The "wasteTime" loop could add numbers, just sit and wait for a
predetermined time or do whatever. The idea here is to not hammer the
machine quite as badly such that the L2 cache doesn't get trashed. The
"wasteTime" loop runs every 50 or so compiles and gives the machine a
chance to recover.

Since I am not too familiar with the configure script  and Makefile
generation I don't think I should start messing around with this. But I
thought I'd throw this out for discussion and see what happens.

P.S.
Before anyone starts yelling "We should create special stuff to work
around hardware issues" there is one thing to consider. The problem with
the L2 cache generally only shows up when building gcc. I have build
Motif, gdb and the Linux kernel on this machine without special
attention to machine load, all worked fine and all compiles are of
reasonable size. Thus the problem is somewhat specific to gcc.

Opinions welcome. I'll also be glad to spend some time on this to get
this feature implemented and tested, but will need some help from some
one who knows this stuff.

Happy Hacking,
Robert

--
Robert Schweikert                      MAY THE SOURCE BE WITH YOU
rjschwei@mindspring.com                         LINUX