I've never seen the answer to the following question: Why do some versions of gcc that I build not have string substitutions in error messages?

I get things like this:

[luc...@lambda-head lib]$ /pkgs/gcc-mainline/bin/gcc -mcpu=970 -m64 - fschedule-insns -Wno-unused -O1 -fno-math-errno -fschedule-insns2 - fno-trapping-math -fno-strict-aliasing -fwrapv -fomit-frame-pointer - fPIC -fno-common -I"../include" -c _thread-test.i -save-temps
_thread.c: In function â:
_thread.c:10035:146: error: â undeclared (first use in this function)
_thread.c:10035:146: error: (Each undeclared identifier is reported only once
_thread.c:10035:146: error: for each function it appears in.)

It makes cutting down a test case for a bug report a bit of guess and hack.

And an unrelated question: I've found on some tests on x86-64 that - fschedule-insns added to -O1 speeds up some of my codes impressively, but on x86-64-linux and powerpc64-linux I've had problems finding spill registers and I've also been getting stuff like

/pkgs/gcc-mainline/bin/gcc -mcpu=970 -m64 -fschedule-insns -save- temps -Wno-unused -O1 -fno-math-errno -fschedule-insns2 -fno-trapping- math -fno-strict-aliasing -fwrapv -fomit-frame-pointer -fPIC -fno- common -I"../include" -c -o "_thread.o" -I. -DHAVE_CONFIG_H - D___GAMBCDIR="\"/usr/local/Gambit-C\"" -D___SYS_TYPE_CPU="\"powerpc64 \"" -D___SYS_TYPE_VENDOR="\"unknown\"" -D___SYS_TYPE_OS="\"linux-gnu \"" -D___CONFIGURE_COMMAND="\"./configure CC=/pkgs/gcc-mainline/bin/ gcc -mcpu=970 -m64 -fschedule-insns\"" -D___OBJ_EXTENSION="\".o\"" - D___EXE_EXTENSION="\"\"" -D___PRIMAL _thread.c -D___LIBRARY
_thread.c: In function â:
_thread.c:15556:1: error: insn does not satisfy its constraints:
(insn 614 220 216 26 _thread.c:15462 (set (reg:DF 20 20)
        (mem:DF (plus:DI (reg:DI 23 23 [orig:199 D.20368 ] [199])
(const_int 23 [0x17])) [0 S8 A64])) 357 {*movdf_hardfloat64} (nil)) _thread.c:15556:1: internal compiler error: in reload_cse_simplify_operands, at postreload.c:396

Actually, I haven't been able to get Gambit to build on any architecture I've tried with -fschedule-insns on the command line.

So, is -fschedule-insns an option to be avoided?

Brad

Reply via email to