Re: Miscompilations for cris-elf on dataflow-branch

["Seongbae Park (박성배, 朴成培)" <seongbae dot park at gmail dot com>]

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