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";
--
#pragma ident "Seongbae Park, compiler, http://seongbae.blogspot.com";
