Miscompilations for cris-elf on dataflow-branch

[Seongbae Park (박성배, 朴成培)]

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 (박성배, 朴成培) <seongbae.park@gmail.com> 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 <hans-peter.nilsson@axis.com> 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"
>


-- 
#pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com"