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