------- Comment #17 from dave at hiauly1 dot hia dot nrc dot ca 2008-06-22 22:43 ------- Subject: Re: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above
> > ------- Comment #15 from dave at hiauly1 dot hia dot nrc dot ca 2008-06-22 > > 21:34 ------- > > Subject: Re: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c > > execution at -O2 and above > > > > > > x$B0F7_8 = BIT_FIELD_REF <x, 7, 0>; > > > > D.1258.i ={v} x$i_5; > > > > D.1258.j ={v} x$j_7; > > > > SR.12_9 = x$B0F7_8 >> 1; > > > > BIT_FIELD_REF <D.1258, 7, 0> ={v} SR.12_9; > > > > return D.1258; > > > > > Well, SRA is broken (cost-wise at least) since lxos changes. > > > > Why the shift? It seems incorrect. > > It looks like it is only assigning the 6-bit part of the k, l > combination. Is the above after the SRA pass in question or after > some more optimizations? It appears first in the esra pass dump: ;; Function retmeK (retmeK) Initial instantiation for x Using element-copy for x x$B0F7 -> x$B0F7 x.j -> x$j x.i -> x$i Initial instantiation for D.1258 Using block-copy for D.1258 Symbols to be put in SSA form { x x$B0F7 x$j x$i SR.10 SR.11 SR.12 SR.13 SR.14 } Incremental SSA update started at block: 0 Number of blocks in CFG: 3 Number of blocks to update: 2 ( 67%) Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518