This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Miscompilations for cris-elf on dataflow-branch
- From: Hans-Peter Nilsson <hans-peter dot nilsson at axis dot com>
- To: zadeck at naturalbridge dot com
- Cc: gcc at gcc dot gnu dot org, seongbae dot park at gmail dot com
- Date: Mon, 11 Jun 2007 04:51:30 +0200
- Subject: Miscompilations for cris-elf on dataflow-branch
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