compiling GHC with a custom path to GCC

[Seth Kurtzberg]

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.
>
>Cheers,
>	Simon
>  
>
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 
evidence.

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
>http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
>!DSPAM:4215baf2198669959829382!
>
>  
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org//pipermail/glasgow-haskell-users/attachments/20050218/625a1d39/attachment-0001.htm