------- 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
