Date:	Mon, 3 Sep 2001 17:26:22 +0300 (IDT)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	Juan Manuel Guerrero <ST001906 AT HRZ1 DOT HRZ DOT TU-Darmstadt DOT De>
cc:	pavenis AT lanet DOT lv, djgpp-workers AT delorie DOT com
Subject:	Re: gcc301 difficulty
In-Reply-To:	<61357C1227C@HRZ1.hrz.tu-darmstadt.de>
Message-ID:	<Pine.SUN.3.91.1010903172031.19586B-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp-workers AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp-workers AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On Mon, 3 Sep 2001, Juan Manuel Guerrero wrote:

> The only way to get gcc-301 working is to disable the internal
> CPU cache (using BIOS settings). Disabling on-board L2 cache has
> no influence.

Such problems generally point to a faulty memory.  So if all the 
modifications you tried used the same memory chips, I'd suggest 
to replace them, or try some different memory configuration (e.g.,
as suggested by Martin).

If that doesn't help either, replace the CPU.  I once detected a
faulty (a bit too slow) Intel clone by compiling a large source
file with GCC.  It's a known fact that a GCC compilation is a good
diagnostic tool, since GCC consumes lots of memory, moves large
buffers to and fro, and runs the CPU at full throttle for prolonged
periods of time.

> I am very sorprised about all this. I have been using gcc30b.zip
> for a month without any difficulty. I expected gcc301b.zip
> to be only a minor bug fix release and not to cause such
> difficulties.

Andris, did you use any different optimization switches when you built 
GCC 3.0.1, or maybe a different version of Binutils (the assembler 
matters the most, I think)?

- Raw text -