Re: porting problem again: ICE in add_clobbers

2007-09-21 Thread Jim Wilson
Tomas Svensson wrote: On 19 Sep 2007 07:54:14 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: gcse will never convert a recognizable insn into an unrecognizable insn. Ok. Do you know of any other reasons why this particular optimization switch would cause this problem? There are millions o

Re: porting problem again: ICE in add_clobbers

2007-09-21 Thread Rask Ingemann Lambertsen
On Tue, Sep 18, 2007 at 12:54:17PM +0200, Tomas Svensson wrote: > > 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. Odd, since

Re: porting problem again: ICE in add_clobbers

2007-09-21 Thread Rask Ingemann Lambertsen
On Fri, Sep 21, 2007 at 04:53:38PM +0200, Tomas Svensson wrote: > (define_expand "bleu" > [(use (match_operand 0 "" ""))] > "" > "expand_branch (LEU, operands[0]); DONE;") > > which is heavily inspired by the or32 port of version 3.4.4, as is > expand_branch(). > But this should not need a ma

Re: porting problem again: ICE in add_clobbers

2007-09-21 Thread Tomas Svensson
On 19 Sep 2007 07:54:14 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > gcse will never convert a recognizable insn into an unrecognizable > insn. Ok. Do you know of any other reasons why this particular optimization switch would cause this problem? > You still haven't showed us the actual i

Re: porting problem again: ICE in add_clobbers

2007-09-19 Thread Ian Lance Taylor
"Tomas Svensson" <[EMAIL PROTECTED]> writes: > So I guess the problem is somehow caused by global common > subexpression elimination. Could it be that gcse changes the insn in > some way, making it unrecognizable by the usual define_insn's? gcse will never convert a recognizable insn into an unre

Re: porting problem again: ICE in add_clobbers

2007-09-19 Thread Tomas Svensson
On 9/18/07, Jim Wilson <[EMAIL PROTECTED]> wrote: > Tomas Svensson wrote: > There is no optimization at all without -O, no matter how many -f > options you use. What you want to do is -O -fno-foo -fno-bar etc. > However, we do not have -f options for every optimization, so there is > no guarantee

Re: porting problem again: ICE in add_clobbers

2007-09-18 Thread Jim Wilson
Tomas Svensson wrote: 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. There is no optimization at all w

Re: porting problem again: ICE in add_clobbers

2007-09-18 Thread Tomas Svensson
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 o

Re: porting problem again: ICE in add_clobbers

2007-09-18 Thread Ian Lance Taylor
"Tomas Svensson" <[EMAIL PROTECTED]> writes: > 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

porting problem again: ICE in add_clobbers

2007-09-18 Thread Tomas Svensson
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 "" ""))