This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c/24486] New: gcc generates incorrect assignment because of reordering


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]