[Bug c/20359] New: Incorrect code with global register variables
Global register variables rear their ugly head again. Here's a simple test case
that generates incorrect code on x86_64 with gcc 3.4.2:
$ cat bug.c
register void * R1 __asm__("%r13");
extern void g(void);
static void f(void) {
R1 = g;
goto *R1;
}
$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--disable-checking --with-system-zlib --enable-__cxa_atexit
--host=i386-redhat-linux
Thread model: posix
gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)
$ gcc -O -S bug.c
The generated code for function f is:
f:
.LFB2:
movl$g, %eax
jmp *%rax
Note the assignment to the global register variable R1 has been lost.
This is breaking the Glasgow Haskell Compiler (http://www.haskell.org/ghc/) on
the x86_64 platform. It might be related to the (closed) bug #7871.
--
Summary: Incorrect code with global register variables
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: simonmar at microsoft dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: x86_64-*-linux
GCC host triplet: x86_64-*-linux
GCC target triplet: x86_64-*-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20359
[Bug rtl-optimization/20359] Incorrect code with global register variables
--- Additional Comments From simonmar at microsoft dot com 2005-03-07 15:11 --- Sorry, cut & pasted that gcc -v output from the wrong window. The bug really does occur with 3.4.2, here's the correct -v output: $ gcc -v Reading specs from /usr/lib/gcc/x86_64-redhat-linux/3.4.2/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man -- infodir=/usr/share/info --enable-shared --enable-threads=posix --disable- checking --with-system-zlib --enable-__cxa_atexit --disable-libunwind- exceptions --enable-languages=c,c++,objc,java,f77 --enable-java-awt=gtk -- host=x86_64-redhat-linux Thread model: posix gcc version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20359
[Bug c/34070] New: Wrong code for (int)x%4
The following code generates the wrong result:
#include
int f(unsigned int x)
{
printf("%x %d\n", x, (int)x);
return ((int)x) % 4;
}
int main(int argc, char *argv[])
{
printf("%d\n", f((unsigned int)(-1)));
return 0;
}
I expect this:
$ gcc-3.4.3 ctest33.c -Wall && ./a.out
-1
-1
and with gcc-4 and greater I get this:
$ gcc-4.2.1 ctest33.c -Wall && ./a.out
-1
3
Why do I think this is a bug? Well, initially I thought I'd run into undefined
behaviour, but on closer reading of the C spec it seems the behaviour should be
implementation-defined, and gcc is not implementing the documented behaviour.
Furthermore, gcc's behaviour is not consistent, as implementation-defined
behaviour should be.
The bug appears to be centered around conversion from unsigned to signed
integers. We convert from unsigned to signed in f(), and the value passed is
0x. The result is therefore implementation-defined (C99 6.3.1.3), and
gcc defines it (section 4.5 of the gcc docs) as: "For conversion to a type of
width N, the value is reduced modulo 2^N to be within range of the type". I
presume this means that the value is truncated to N bits and the result
interpreted as twos-complement, which in this case should mean that (int)x is
-1, and the expression is (-1 % 4), which has value -1.
We can see from the printf output that (int)x has value -1. Since this is its
implementation-defined value, it should have the same value in the expression
(int)x % 4.
Indeed, several minor variations of this code give the expected output.
Substituting 0xU for x in the definition of f(), for example.
Optimisation level has no effect. Bug also observed on i686-unknown-linux.
--
Summary: Wrong code for (int)x%4
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: simonmar at microsoft dot com
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34070
[Bug c/26824] New: optimisation bug with -0x80000000
The following code is compiled incorrectly with -O2:
#include
void f(int x) {
if (x < 0) {
if (-x > 0) {
exit(1);
}
}
}
int main() {
f(-0x8000);
exit(0);
}
$ gcc foo.c; ./a.out
$ gcc -O2 foo.c; ./a.out
zsh: 4407 exit 1 ./a.out
$
--
Summary: optimisation bug with -0x8000
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: simonmar at microsoft dot com
GCC build triplet: x86_64-redhat-linux
GCC host triplet: x86_64-redhat-linux
GCC target triplet: x86_64-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26824
[Bug c/26824] optimisation bug with -0x80000000
--- Comment #5 from simonmar at microsoft dot com 2006-03-23 15:10 ---
I see your point, but I still think there's a bug. Let me change the code
slightly:
#include
#include
void f(int x) {
long y;
if (x < 0) {
y = -x;
if (y > 0) {
printf("%d\n",y);
}
}
}
int main() {
f(-0x8000);
exit(0);
}
$ gcc -O2 foo.c
$ ./a.out
-2147483648
so, we're in the y > 0 branch, but y is clearly < 0.
--
simonmar at microsoft dot com changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Component|middle-end |c
Resolution|INVALID |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26824
