This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Testing -fnew-ra (and GCC in general)


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?

--
Scott Robert Ladd
Coyote Gulch Productions (http://www.coyotegulch.com)
Software Invention for High-Performance Computing


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]