compiling GHC with a custom path to GCC
seth at cql.com
Fri Feb 18 05:17:23 EST 2005
Simon Marlow wrote:
>On 18 February 2005 04:26, Seth Kurtzberg wrote:
>>At least this proves that it isn't a hardware problem. :)
>Seth, you're a bit confused. This error from gcc is a deterministic,
>repeatable, crash due to a known bug in gcc 2.95.
>You were complaining about random unrepeatable crashes, which are most
>likely caused by hardware failure. We never said that deterministic
>crashes in gcc are due to hardware.
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. You know that isn't true. You
can, on the same machines, compile the same code with a different
compiler hundreds of times (which I did; I left it running on two
machines for a month) without a single problem. That is a software problem.
I make a living by determining whether problems are software or
hardware, and I very rarely make a mistake. I certainly never make a
mistake with this sort of overwhelming proof. You are just ignoring the
things that I've said that don't fit your theory. You will not find a
single case of this caused by hardware, because if the hardware is
really responsible, it is 100% impossible that every other program,
including programs that consume all the memory and most of the swap
(consume more total memory than the gcc runs) always work perfectly, and
only gcc causes this supposedly hardware problem to appear. 100
machines, of six different microprocessors, and six different types of
memory, all have a hardware problem that causes gcc, and only gcc, and
absolutely nothing other than gcc, to crash? These machines can
otherwise run for months at a time at very high load and the hardware
problem somehow never appears?
Tell me that you've ever seen a hardware problem with these
characteristics. Furthermore, tell me that you've seen hardware
problems that never get worse, and are associated with a single
program. Find a single example of such a program that reveals a
hardware problem in processors made by three different companies. Or an
example of a program that reveals a hardware problem in a dozen
different motherboards. None of which exhibit even the slightest
problem unless gcc is running. None of which deadlock, freeze up, never
have kernel panics ... it just isn't possible, unless you ignore the
And the fact that one is deterministic implies that the others are not?
That has absolutely no basis in logic. I'm sure that with enough work
each and every one can be produce deterministically. Nobody has paid me
to do that, and nobody is going to. It's a lot cheaper to just use a
compiler that works. Even having to use Sun's compiler, with all it's
problems, is less expensive then trying to fix gcc, and Sun charges
about 3,000 each for the compiler.
Hardware problems cause random problems, and any problem that occurs
with only one program is by definition not random. You are confusing
random with not yet explained. The two aren't remotely alike.
>Glasgow-haskell-users mailing list
>Glasgow-haskell-users at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Glasgow-haskell-users