I have investigated it further, and thought I'd add it to my question.
I have tried compiling with all optimization flags turned on manually
(list included below) and that compiles just fine. That leads me to
think that what is causing the bug is some undocumented optimization,
triggered only if optimize > 0. Unfortunately, this is checked for all
over the source, and I still have no idea where to start looking, so
if anyone recognizes this, please let me know!
My original question is included below. The optimization switches I've
turned on are:
-falign-functions -falign-jumps -falign-loops -falign-labels
-freorder-blocks -fdefer-pop -fdelayed-branch
-fguess-branch-probability -fcprop-registers -floop-optimize
-fif-conversion -fif-conversion2 -ftree-ccp -ftree-dce
-ftree-dominator-opts -ftree-dse -ftree-ter -ftree-lrs -ftree-sra
-ftree-copyrename -ftree-fre -ftree-ch -funit-at-a-time
-fmerge-constants -fthread-jumps -fcrossjumping
-foptimize-sibling-calls -fcse-follow-jumps -fcse-skip-blocks -fgcse
-fgcse-lm -fgcse-sm -fgcse-las -fexpensive-optimizations
-fstrength-reduce -frerun-cse-after-loop -frerun-loop-opt
-fcaller-saves -fpeephole2 -fschedule-insns -fschedule-insns2
-fsched-interblock -fsched-spec -fregmove -fstrict-aliasing
-fdelete-null-pointer-checks -freorder-functions -ftree-vrp -ftree-pre
-fomit-frame-pointer -fforce-mem
On 9/18/07, Tomas Svensson <[EMAIL PROTECTED]> wrote:
> I am still porting gcc v4.1.2 to a new risc architecture, and this
> time my problem is that when compiling with -O2 turned on, every insn
> with a (use ..) side effect expression, eg.
>
> (define_expand "sibcall"
> [(parallel [(call (match_operand 0 "" "")
> (match_operand 1 "" ""))
> (use (match_operand 2 "" ""))
> (use (match_operand 3 "" ""))])]
> "TARGET_SIBCALL"
> {
> if (operands[3] == NULL_RTX)
> operands[3] = const0_rtx;
>
> internal_expand_sibcall (0, XEXP (operands[0], 0), operands[1]);
> DONE;
> })
>
> causes the compiler to fail with an internal compiler error in add_clobbers.
>
> I have looked at it in gdb and it fails on reaching the
> gcc_unreachable() in add_clobbers, which happens because add_clobbers
> is called (at combine.c:9576) with an insn_code_number that it does
> not recognize.
>
> Everything works fine when optimization is turned off. What is it that
> gcc does differently when optimizing, that might cause this to happen?
>
