This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: RFC/RFA: patch for PR 22156: improve SRA for bit-fields


On 3/24/07, Alexandre Oliva <aoliva@redhat.com> wrote:
> I found and fixed another bug in the type used for the replacement
> BIT_FIELD_REF for a field block, which was causing some trouble
> building the Ada rts (great testcases there! ;-)

There were a number of other problems, some minor, some major, in the
last patch I posted.  This one has actually survived bootstrap on
x86_64-linux-gnu and i686-pc-linux-gnu without any regressions (*),
and it built sh-elf and arm-eabi crosses, with manual testing to
verify proper functioning of the endianness-dependent bits.  The
testsuite wouldn't run in a unified tree.

This causes a couple of failures on spu-elf: FAIL: gcc.c-torture/execute/20040709-2.c execution, -O1 FAIL: gcc.c-torture/execute/20040709-2.c execution, -O2 FAIL: gcc.c-torture/execute/20040709-2.c execution, -O3 -fomit-frame-pointer FAIL: gcc.c-torture/execute/20040709-2.c execution, -O3 -fomit-frame-pointer -funroll-loops FAIL: gcc.c-torture/execute/20040709-2.c execution, -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions FAIL: gcc.c-torture/execute/20040709-2.c execution, -O3 -g FAIL: gcc.c-torture/execute/20040709-2.c execution, -Os

FAIL: gcc.c-torture/execute/991118-1.c execution,  -O3 -fomit-frame-pointer
FAIL: gcc.c-torture/execute/991118-1.c execution,  -O3 -g
FAIL: gcc.c-torture/execute/991118-1.c execution,  -Os
FAIL: gcc.c-torture/execute/bf64-1.c execution,  -O3 -fomit-frame-pointer
FAIL: gcc.c-torture/execute/bf64-1.c execution,  -O3 -g
FAIL: gcc.c-torture/execute/bf64-1.c execution,  -Os

For 991118-1.c:

We go from:
tmpD.2291 = tmpD.2252;
tmp$padD.2292_9 = tmpD.2291.padD.2209;
tmp$fieldD.2293_10 = tmpD.2291.fieldD.2210;
D.2294_11 = (long long intD.5) tmp$fieldD.2293_10;
D.2295_12 = D.2294_11 ^ 2381903268435576;
D.2296_13 = (<unnamed-signed:52>) D.2295_12;
D.2297.padD.2209 = tmp$padD.2292_9;
D.2297.fieldD.2210 = D.2296_13;
tmp.0D.2258 = D.2297;
tmpD.2252 = tmp.0D.2258;
tmp2D.2298 = tmp2D.2253;

To:
tmp$fieldD.2323_29 = tmpD.2252.fieldD.2210;
tmp$padD.2324_30 = tmpD.2252.padD.2209;
tmp$padD.2292_9 = tmp$padD.2324_30;
tmp$fieldD.2293_10 = tmp$fieldD.2323_29;
D.2294_11 = (long long intD.5) tmp$fieldD.2293_10;
D.2295_12 = D.2294_11 ^ 2381903268435576;
D.2296_13 = (<unnamed-signed:52>) D.2295_12;
SR.19D.2326_31 = tmp$padD.2292_9;
SR.18D.2325_32 = D.2296_13;
SR.32D.2339_34 = SR.12D.2319_33(D) & 0x0fff0000000000000;

in the early SRA.

See how SR.12D.2319_33(D) is the default SSA name, that is the bug.

Thanks,
Andrew Pinski


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]