Seongbae Park (박성배, 朴成培) wrote: > This little patch: > > diff -r 9e2b1e62931a gcc/combine.c > --- a/gcc/combine.c Wed Jun 06 23:08:38 2007 +0000 > +++ b/gcc/combine.c Mon Jun 11 05:39:25 2007 +0000 > @@ -4237,7 +4237,7 @@ subst (rtx x, rtx from, rtx to, int in_d > > So force this insn not to match in this (rare) case. */ > if (! in_dest && code == REG && REG_P (from) > - && REGNO (x) == REGNO (from)) > + && reg_overlap_mentioned_p (x, from)) > return gen_rtx_CLOBBER (GET_MODE (x), const0_rtx); > > /* If this is an object, we are done unless it is a MEM or LO_SUM, both > > should fix the problem (thanks to Ian Lance Talyor and Andrew Pinski > for helping me debug the problem on IRC). > I've started the bootstrap/regtest on x86-64. > I'd appreciate it if you can test this on cris. > Although the change is approved by Ian already, > I think I'll hold the patch till the dataflow merge happens. > Thanks, > > Seongbae > > On 6/10/07, Seongbae Park (박성배, 朴成培) <[EMAIL PROTECTED]> > wrote: >> Thanks for the detailed instruction on how to reproduce it >> - I have successfully reproduced the problem, and narrowed it down >> to combine that's deleting the insn in question. >> Hopefully I'll be able to figure out what's wrong soon. >> >> Seongbae >> >> On 6/10/07, Hans-Peter Nilsson <[EMAIL PROTECTED]> wrote: >> > I hear dataflow-branch is near merge to trunk, so I thought it'd >> > be about time to verify that it works for the targets I >> > maintain... >> > >> > Comparing dataflow-branch with trunk, both r125590, I see these >> > regressions (alas no improvements) on the branch for cris-elf >> > cross from x86_64-unknown-linux-gnu (Debian etch, I think): >> > >> > gcc.sum gcc.c-torture/execute/20020201-1.c >> > gcc.sum gcc.c-torture/execute/20041011-1.c >> > gcc.sum gcc.c-torture/execute/920501-8.c >> > gcc.sum gcc.c-torture/execute/920726-1.c >> > gcc.sum gcc.c-torture/execute/ashldi-1.c >> > gcc.sum gcc.c-torture/execute/ashrdi-1.c >> > gcc.sum gcc.c-torture/execute/builtin-bitops-1.c >> > gcc.sum gcc.c-torture/execute/builtins/pr23484-chk.c >> > gcc.sum gcc.c-torture/execute/builtins/snprintf-chk.c >> > gcc.sum gcc.c-torture/execute/builtins/sprintf-chk.c >> > >> > Though repeatable by anyone (see for example >> > <http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01571.html>), all >> > are unfortunately execution failures, so I thought best to do >> > some preliminary analysis. >> > >> > Looking at the source code for what the tests have in common, it >> > seems all either use sprintf "%d" or a DImode shift operation >> > (requiring a library call). My money is on all being the same >> > one bug. >> > >> > Here's a cut-down test-case, derived from >> > gcc.c-torture/execute/builtin-bitops-1.c: >> > >> > ---------- >> > static int >> > my_popcountll (unsigned long long x) >> > { >> > int i; >> > int count = 0; >> > for (i = 0; i < 8 * sizeof (unsigned long long); i++) >> > if (x & ((unsigned long long) 1 << i)) >> > count++; >> > return count; >> > }; >> > >> > extern void abort (void); >> > extern void exit (int); >> > >> > int >> > main (void) >> > { >> > int i; >> > >> > if (64 != my_popcountll (0xffffffffffffffffULL)) >> > abort ();; >> > >> > exit (0); >> > } >> > ---------- >> > >> > Here's the assembly diff to trunk, revisions as per above, >> > option -Os as mentioned below: >> > >> > --- lshr1.s.trunk 2007-06-11 03:49:21.000000000 +0200 >> > +++ lshr1.s.df 2007-06-11 03:49:59.000000000 +0200 >> > @@ -15,7 +15,6 @@ _main: >> > move.d ___lshrdi3,$r2 >> > moveq -1,$r10 >> > .L7: >> > - move.d $r10,$r11 >> > move.d $r0,$r12 >> > Jsr $r2 >> > btstq (1-1),$r10 >> > >> > To repeat this without building a complete toolchain, have a gcc >> > svn checkout with those darned mpfr and gmp available somewhere >> > (added in that checkout or installed on the host system), then >> > do, in an empty directory: >> > /path/to/gcctop/configure --target=cris-elf --enable-languages=c && >> make all-gcc >> > This will give you a cc1, which you know how to handle. :) >> > >> > To repeat with the program above named lshr1.c, just use: >> > >> > ./cc1 -Os lshr1.c >> > >> > The lost insn, numbered 61 in both trees, loads the high part of >> > that all-bits operand to the register in which that part of the >> > parameter is passed to the DImode left-shift library function >> > __lshrdi3. From the dump-file it seems the first pass it is >> > lost, is combine. >> > >> > Let me know if I can be of help. >> > >> > brgds, H-P >> > >> >> >> -- >> #pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com"; >> > > thanks for looking at this. i had gone to bed..
kenny
