This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c/24486] New: gcc generates incorrect assignment because of reordering
- From: "manus at eiffel dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 22 Oct 2005 16:05:06 -0000
- Subject: [Bug c/24486] New: gcc generates incorrect assignment because of reordering
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
Below you will find the C code for which I believe `gcc' generates an incorrect
assignment in `my_buggy_routine' (below) because it computes the destination
address too early. In other word, the assignment:
*(char *)(Current + 9) = my_computation (Current, i);
as the effect of
char * tmp = Current + 9
*tmp = my_computation (Current, i);
but this is incorrect because `Current' was actually modified by
`my_computation' and thus we assign to the wrong location.
I believe 3.x and earlier version of `gcc' were not doing that.
The version of gcc I'm using is the one that comes in Fedora Core 4 running on
a AMD64:
gcc (GCC) 4.0.0 20050519 (Red Hat 4.0.0-8)
The command line I'm using to compile `bug.c' is the following:
gcc -Wall -g bug.c -o bug
There are no errors/warnings triggered by this compilation.
Here is the `bug.c' file:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
typedef char * REFERENCE;
static REFERENCE * stack [10];
char my_computation (REFERENCE Current, int i) {
*stack[0] = *stack[0] + 10;
return 'a';
}
void my_buggy_routine (REFERENCE Current, int i) {
stack[0] = &Current;
*(char *)(Current + 9) = my_computation (Current, i);
}
int main () {
REFERENCE Current;
Current = (REFERENCE) malloc (100);
memset (Current, 0, 10);
my_buggy_routine (Current, 10);
return 0;
}
For reporting the bug, I've used the following command line:
gcc -Wall -g bug.c -o bug -v -save-temps
Which generates the following output
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,java,f95,ada --enable-java-awt=gtk
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre
--host=x86_64-redhat-linux
Thread model: posix
gcc version 4.0.0 20050519 (Red Hat 4.0.0-8)
/usr/libexec/gcc/x86_64-redhat-linux/4.0.0/cc1 -E -quiet -v bug.c -mtune=k8
-Wall -fworking-directory -fpch-preprocess -o bug.i
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-redhat-linux/4.0.0/../../../../x86_64-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/usr/lib/gcc/x86_64-redhat-linux/4.0.0/include
/usr/include
End of search list.
/usr/libexec/gcc/x86_64-redhat-linux/4.0.0/cc1 -fpreprocessed bug.i -quiet
-dumpbase bug.c -mtune=k8 -auxbase bug -g -Wall -version -o bug.s
GNU C version 4.0.0 20050519 (Red Hat 4.0.0-8) (x86_64-redhat-linux)
compiled by GNU C version 4.0.0 20050519 (Red Hat 4.0.0-8).
GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128087
as -V -Qy -o bug.o bug.s
GNU assembler version 2.15.94.0.2.2 (x86_64-redhat-linux) using BFD version
2.15.94.0.2.2 20041220
/usr/libexec/gcc/x86_64-redhat-linux/4.0.0/collect2 --eh-frame-hdr -m
elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o bug
/usr/lib/gcc/x86_64-redhat-linux/4.0.0/../../../../lib64/crt1.o
/usr/lib/gcc/x86_64-redhat-linux/4.0.0/../../../../lib64/crti.o
/usr/lib/gcc/x86_64-redhat-linux/4.0.0/crtbegin.o
-L/usr/lib/gcc/x86_64-redhat-linux/4.0.0
-L/usr/lib/gcc/x86_64-redhat-linux/4.0.0
-L/usr/lib/gcc/x86_64-redhat-linux/4.0.0/../../../../lib64
-L/usr/lib/gcc/x86_64-redhat-linux/4.0.0/../../.. -L/lib/../lib64
-L/usr/lib/../lib64 bug.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc
--as-needed -lgcc_s --no-as-needed
/usr/lib/gcc/x86_64-redhat-linux/4.0.0/crtend.o
/usr/lib/gcc/x86_64-redhat-linux/4.0.0/../../../../lib64/crtn.o
Thanks for looking into that matter.
Regards,
Manu
--
Summary: gcc generates incorrect assignment because of reordering
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: blocker
Priority: P1
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: manus at eiffel dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24486