[Bug inline-asm/11807] GCC should error out when clobbering the stack pointer and frame pointer
--- Comment #27 from dpm at danger dot com 2007-01-30 18:20 --- Bug 30579 was marked as a duplicate of this bug. If I compile the test case from that bug with -fomit-frame-pointer, gcc still generates invalid code. (We don't use frame pointers in our system at all). Is this already known? It seems like gcc should support clobbering of fp if you've disabled frame pointers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11807
[Bug regression/30173] New: Regression in ARM softfloat routine __adddf3
Version Information
[EMAIL PROTECTED] ~]$ arm-elf-gcc -v
Using built-in specs.
Target: arm-elf
Configured with: ../gcc-4.1.1/configure
--prefix=/usr/local/armdev-926ej-s-4.1.1 --target=arm-elf --enable-languages=c
--with-float=soft --enable-interwork --enable-multilib --with-cpu=arm926ej-s
--disable-threads --with-dwarf2 --without-headers
Thread model: single
gcc version 4.1.1
[EMAIL PROTECTED] ~]$
Introduction
This bug was found by building Danger's Java platform using GCC 4.1.1 and
running it against the Java ME CLDC TCK 1.1a. The test suite had previously
passed when building our Java platform against GCC 3.4.3, so the new test
failures constituted a regression. The proposed fix was confirmed to correct
the failing tests without introducing other failures in the test suite.
The bug should be reproducible using the appended .i file when compiler
optimizations are disabled; however, I cannot confirm that because our embedded
product requires our supporting OS. If I try to compile this test, I get the
following link error:
[EMAIL PROTECTED] ~]$ arm-elf-gcc -save-temps -o test test.c
/usr/local/armdev-926ej-s-4.1.1/lib/gcc/arm-elf/4.1.1/../../../../arm-elf/bin/ld:
crt0.o: No such file: No such file or directory
collect2: ld returned 1 exit status
Analysis of the bug
The test case should simply return; however, on our system it goes into an
infinite loop. The cause of the bug is found in the function __adddf3 in
gcc/config/arm/ieee754-df.S. In the test case, the inputs to this function are:
r0 1000
r1 0001
r2
r3
Hand simulation of the code shows that r4 and r5 are set as follows:
r4
r5
__adddf3 correctly identifies that 0.0 is one of the inputs. As a result, we
branch to LSYM(Lad_s) and then reach this comment:
@ Result is x + 0.0 = x or 0.0 + y = y.
It is here that we encounter the bug. The code tries to determine which
argument is 0.0 by testing r4.
teq r4, #0
If the test passes, the first argument is thought to be 0.0, so the second
argument is moved into r0/r1 for return, and the function exits. If the test
fails, the function exits directly, returning the first argument.
This test is insufficient when the first argument is a very small number. In
that case, r4 will be 0, but the first argument overall will be non-zero. As a
result, the function returns the second argument when it should have returned
the first.
To fix the bug, the following line should be inserted after the above line:
teqeq xl, #0
This verifies that the entire first argument is indeed 0, not just the high 32
bits.
test.i file
[EMAIL PROTECTED] ~]$ cat test.i
# 1 "test.c"
# 1 ""
# 1 ""
# 1 "test.c"
int
main()
{
double x = -4.9E-324;
double y = +0.0;
double z = x + y;
while (z != x)
;
return 0;
}
Full unified patch:
--- ieee754-df.S.orig 2006-12-06 14:57:12.0 -0800
+++ ieee754-df.S2006-12-06 14:57:30.0 -0800
@@ -327,6 +327,7 @@
@ Result is x + 0.0 = x or 0.0 + y = y.
teq r4, #0
+ teqeq xl, #0
moveq xh, yh
moveq xl, yl
RETLDM "r4, r5"
--
Summary: Regression in ARM softfloat routine __adddf3
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dpm at danger dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30173
[Bug inline-asm/30579] New: Clobbered hard register is not restored before subsequent use
Version Information
[EMAIL PROTECTED] ~]$ arm-elf-gcc -v
Using built-in specs.
Target: arm-elf
Configured with: ../gcc-4.1.1/configure
--prefix=/usr/local/armdev-926ej-s-4.1.1 --target=arm-elf --enable-languages=c
--with-float=soft --enable-interwork --enable-multilib --with-cpu=arm926ej-s
--disable-threads --with-dwarf2 --without-headers
Thread model: single
gcc version 4.1.1
[EMAIL PROTECTED] ~]$
Reproduction Steps
[EMAIL PROTECTED] ~]$ arm-elf-gcc -Os -save-temps -c -S sample.c
[EMAIL PROTECTED] ~]$
[ sample.i attached to this bug report ]
Analysis of the bug
The bug appears in the generated assembly of the function gc_lock_held(int).
The function gc_memmove_down(void *, const void *, size_t) is inlined into this
function during compilation. That function includes the following inline
assembly statement:
asm("0:\t"
"ldmia %[src]!, { r4 - r11 }\n\t"
"stmia %[dest]!, { r4 - r11 }\n\t"
"sub %[count], %[count], #32\n\t"
"cmp %[count], #32\n\t"
"bhs 0b\n\t"
: [src] "+r" (src), [dest] "+r" (dest), [count] "+r" (count)
:
: "r4", "r5", "r6", "r7", "r8", "r9", "r10", "r11", "cc",
"memory");
The statement lists several clobbered hard registers, as described in this part
of the GCC manual:
http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Extended-Asm.html#Extended-Asm. In
particular, "r11" is one of the clobbered hard registers. In the ARM
architecture, "r11" is a synonym for "fp". This inline assembly statement is
exported into the generated .s file on line 215.
The bug appears on line 241, where we see the following instruction:
str r3, [fp, #0]
A quick hand simulation of the generated assembly code shows that we can reach
this statement without reloading a valid value into fp. Thus, fp is
dereferenced despite having been clobbered by the inline assembly statement.
Because "r11" was listed as a clobbered hard register, gcc should have restored
the value of this register before using it.
Replacing "r11" with "fp" in the clobbered hard register list does not change
the generated code.
--
Summary: Clobbered hard register is not restored before
subsequent use
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dpm at danger dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30579
[Bug inline-asm/30579] Clobbered hard register is not restored before subsequent use
--- Comment #1 from dpm at danger dot com 2007-01-24 21:59 --- Created an attachment (id=12951) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12951&action=view) Reproducible test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30579
