compiling GHC with a custom path to GCC

Seth Kurtzberg seth at
Fri Feb 18 21:39:28 EST 2005

Simon Marlow wrote:

>On 18 February 2005 10:17, Seth Kurtzberg wrote:
>>Simon, you'll never give up.  The crashes are absolutely repeatable. 
>>The fact that I haven't identified a deterministic way to reproduce
>>them does not in any way imply that a deterministic way to reproduce
>>them does not exist.  And, as I've said, you are essentially claiming
>>that a total of over 100 machines all have the same hardware problem,
>>that never ever occurs unless gcc is running.
>I'm not *claiming* anything about your case - please read what I said.
>I simply commented that random crashes in gcc are often caused by
>hardware failure.  Indeed it sounds like hardware isn't the problem in
>your case, so I suggest you try to narrow down the problem and submit a
>report to the gcc folks.
>	Simon
The gcc folks know about the problem, they just don't know how to fix 
it.  I've sent them about 30 core files and many valgrind runs showing 
heap corruption.

I have actually never seen a random crash in gcc, with a coherent core 
dump file, caused by hardware.  This is much much too regular to even 
suspect hardware.

You also have the fact that these machines can run ghc or ghci all day 
long.  ghc is a heavier user of resources, and a much more complex 
program, but it never crashes these systems (except occasionally during 
these initial release or pre-release periods, which is of course to be 
expected).  _If_ a random crash were caused by hardware, other programs 
would _always_ occasionally crash.  There are no exceptions to this 
rule, unless you never run any program other than gcc that uses 
significant resources (and even then I'd be dubious).

It's been happening for so long, and the gcc people have no concept of 
what's happening, so people don't even bother to report it anymore.  Gcc 
3.1 and 3.2 were simply rejected by almost all users because of the 
frequency of crashes.  With 3.3, the crashes did not disappear, but 
became less common.  The initial 3.4 release was unusable.  All of these 
things are well known to anyone working on a C++ project.

I would think that, in addition to showing the ghc is a far superior 
piece of software, the fact that ghc or ghci, once built, never crashes 
would eliminate any doubt about whether the problem is caused by 
hardware or software.

>Glasgow-haskell-users mailing list
>Glasgow-haskell-users at

-------------- next part --------------
An HTML attachment was scrubbed...

More information about the Glasgow-haskell-users mailing list