Re: Not the memory

["Martin v. Loewis" <martin at loewis dot home dot cs dot tu-berlin dot de>]

> The trick is that loop calls abort() does anyone have any clue when this
> happens and why? This will hopefully point me in a direction of a fix.

It means that a NOTE_INSN_LOOP_END was found without any prior
NOTE_INSN_LOOP_BEG, which, of course, can never happen. I recommend
setting a break point on find_and_verify_loops, with a condition that
f is what it is in your case, and see whether the insn list is really
that corrupted. 

The next thing would then be to find out where it gets corrupted. You
could try to determine where the NOTE_INSN_LOOP_END is emitted, either
with a memory watchpoint, or by breaking on the three places where
NOTE_INSN_LOOP_END is emitted.

Please note that there is still no conclusive evidence that there is a
bug in gcc: It could be that your machine corrupts certain locations
in memory, which then results in gcc finding inconsistent data
structures. It doesn't have to be the memory hardware - a buggy device
driver could trigger the same effect. I remember a case where ReiserFS
would cause "random" compilation failures, by reading data off the
disk that had never been written.

> One more thing. I get the core dump only when I run "make", running
> "make bootstrap" hangs the system and I have to push reset, which of
> course is not the preferred way to shutdown the machine.

No matter what bug there is in the compiler, it should not make the
system hang, wouldn't you agree? So if the compiler manages to hang
the system, there must be a problem with the system - potentially the
same problem that causes the compilation to crash.

Regards,
Martin