Experiencing unreproducible internal compiler errors <<whinge>>

[Matt Lowry]

On Thu, 16 Mar 2000, Toon Moene wrote:

> Zack Weinberg wrote:
> 
> > On Thu, Mar 16, 2000 at 12:23:38PM +1030, Matt Lowry wrote:
> 
> > > I have encountered internal compiler errors with gcc 2.95.2, but they are
> > > unreproducible in that with all cases the problem did not reappear when
> > > make was immediatley reinvoked.
> 
> > 99 times out of 100, this is a hardware problem, such as an
> > excessively overclocked CPU or a faulty memory board.  Please see
> > http://www.bitwizard.nl/sig11/
> 
> However, in the past we've also seen this behaviour with experimental OS
> kernels (like the odd-numbered Linux ones).
> 
> Remember that a buggy device driver is a great way to change memory you
> think is private to your process in inpredictable ways.
> 

Sorry folks but this explaination just does not wash with me. I appreciate
the perils of a flakey OS and realise that hardware can do funny things,
but Mandrake 7.0 runs kernel 2.2.14 and my machine is new with (presumably)
decent memory on a decent board with a K7 that is not overclocked.

OK so let's posit it's the hardware. Why isn't every single process running
on the machine liable to having it's memory corrupted or whatever. What's
so special about GCC that means it and nothing else randomly segfaults or
has non-deterministic behaviour despite a decidedly deterministic function
in life? I've yet to see anything else on my machine exhibit this kind of
behaviour.

The same goes for a flakey device driver or what have you. Surely there's
nothing special about GCC that would make it susceptible to this pitfall
and not anything else that I run.

And all that aside, why has this only happened for two particular packages
I've compiled up, and not any of the many others I've done the same for?
This has happened four times during what would be about 5% of the
compilation activity I've engaged in on this machine, and no times in the
remaining 95%. This does not seem the product of a random non-GCC problem.
The really wierd thing is that the two packages, once successfully
compiled, do not seem to be misbehaving. So the code, when generated,
seems good ... well I suppose GCC bugs that cause dodgey code are the easy
one to find ...

Enjoy!
------------------------------------------------
 Matt Lowry      ( mclowry@cs.adelaide.edu.au )
------------------------------------------------
Give a man a beer and he will waste an hour.
Teach a man to homebrew and he will waste a lifetime.
------------------------------------------------