Re: Testing -fnew-ra (and GCC in general)

[<tm_gccmail at kloo dot net>]

On Thu, 16 Oct 2003, Scott Robert Ladd wrote:

AFAIK -fnew-ra is trivially broken in mainline and has been for quite some
time.

IIRC, there's a problem where if a BB ends with a call insn, new-ra will
kludge a dummy insn with a REG_USES note of the return register and
append it to the BB to prevent some code in new-ra from failing.

Unfortunately, this causes some sanity checks elsewhere to fail and the
compiler will ICE.

I filed a PR for this about two or three months ago and afaik it hasn't
been fixed yet.

Toshi

> I've logged into bugzilla (#12619) details of a gcc 3.4 (and g++) bug 
> that was uncovered by my evolutionary tests. I'm not looking for a 
> solution here, but rather I'm wondering about the "stablity" of -fnew-ra 
> (which is involved in both instances of the bug).
> 
> My Acovea program was designed to find sets of options that produce the 
> fastest code -- and as an added "bonus", it seems to be finding compiler 
> bugs. The program tries thousands of option combinations in any given 
> run, serendipitously finding combos that generate ICEs. I suppose this 
> is a "good" thing from the standpoint of testing gcc, although it does 
> raise havoc to my search for optimal optimization options.
> 
> Here are the two (somewhat contradictory) command lines that generate 
> the ICE in my benchmarks:
> 
> gcc -lm -lrt -O1 -march=pentium4 -fgcse -finline-functions -fnew-ra 
> almabench.c
> 
> g++ -lm -lrt -march=pentium4 -fno-inline -fnew-ra fftbench.cpp
> 
> Several people have urged me to evolve option sets using -fnew-ra; yet, 
> at this point, I'm going to need to disable -fnew-ra from my framework, 
> as its presence sterilizes my evolutionary algorithm via ICEs. (Sort of 
> like big asteroids wiping out dinosaurs, I guess.)
> 
> Is -fnew-ra "ready for prime time", or is it still too experimental for 
> serious use?
> 
>