User account creation filtered due to spam.

Bug 27114 - [4.1/4.2 Regression] Bug under optimization. (cast to reference)
Summary: [4.1/4.2 Regression] Bug under optimization. (cast to reference)
Status: RESOLVED DUPLICATE of bug 21920
Alias: None
Product: gcc
Classification: Unclassified
Component: rtl-optimization (show other bugs)
Version: 4.1.0
: P3 normal
Target Milestone: 4.1.1
Assignee: Not yet assigned to anyone
URL:
Keywords: wrong-code
Depends on:
Blocks:
 
Reported: 2006-04-11 06:55 UTC by Dirk Bonekaemper
Modified: 2006-04-11 10:33 UTC (History)
60 users (show)

See Also:
Host: i686-pc-linux-gnu
Target: i686-pc-linux-gnu
Build:
Known to work: 4.0.3
Known to fail:
Last reconfirmed: 2006-04-11 08:28:33


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dirk Bonekaemper 2006-04-11 06:55:53 UTC
The following code aligns and increments a pointer twice. I expect an offset of 8 with respect to the original address. Works as expected with an unoptimized build, but an an offset of 4 is reported when compiled with -O2. The problem seems to be the cast to (long&) before the arithmetic operations in the inline align() function. Removing the (in case of char*) unnecessary first cast will produce the correct output.

--- begin code ---
#include <stdio.h>

struct Test
{
    char *p;
};

inline void align(char* &p)
{
    ((long &)p) += 3;
    ((long &)p) &= -4;
}

int main()
{
    char buffer[8] = {0};
    Test t = { buffer };

    align(t.p);
    t.p += 4;
    align(t.p);
    t.p += 4;

    printf("%d\n", t.p - buffer);
}
--- end code ---
--- begin output ---
> g++ -v -Wall -O2 gcc-4-1-bug.cxx
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.1.0/configure --prefix=/space/gcc-4.1.0 --enable-languages=c,c++
Thread model: posix
gcc version 4.1.0
 /space/gcc-4.1.0/libexec/gcc/i686-pc-linux-gnu/4.1.0/cc1plus -quiet -v -D_GNU_SOURCE gcc-4-1-bug.cxx -quiet -dumpbase gcc-4-1-bug.cxx -mtune=pentiumpro -auxbase gcc-4-1-bug -O2 -Wall -version -o /tmp/cc1idx2e.s
ignoring nonexistent directory "/space/gcc-4.1.0/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /space/gcc-4.1.0/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../include/c++/4.1.0
 /space/gcc-4.1.0/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../include/c++/4.1.0/i686-pc-linux-gnu
 /space/gcc-4.1.0/lib/gcc/i686-pc-linux-gnu/4.1.0/../../../../include/c++/4.1.0/backward
 /usr/local/include
 /space/gcc-4.1.0/include
 /space/gcc-4.1.0/lib/gcc/i686-pc-linux-gnu/4.1.0/include
 /usr/include
End of search list.
GNU C++ version 4.1.0 (i686-pc-linux-gnu)
        compiled by GNU C version 4.1.0.
GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128169
Compiler executable checksum: 4ff5a0850335423f0b9670917725c57b
 as -V -Qy -o /tmp/ccK9mBVm.o /tmp/cc1idx2e.s
GNU assembler version 2.16.91.0.2 (i586-suse-linux) using BFD version 2.16.91.0.2 20050720 (SuSE Linux)
 /space/gcc-4.1.0/libexec/gcc/i686-pc-linux-gnu/4.1.0/collect2 --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o /usr/lib/crti.o /space/gcc-4.1.0/lib/gcc/i686-pc-linux-gnu/4.1.0/crtbegin.o -L. -L/usr/local/lib -L/space/gcc-4.1.0/lib/gcc/i686-pc-linux-gnu/4.1.0 -L/space/gcc-4.1.0/lib/gcc/i686-pc-linux-gnu/4.1.0/../../.. /tmp/ccK9mBVm.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /space/gcc-4.1.0/lib/gcc/i686-pc-linux-gnu/4.1.0/crtend.o /usr/lib/crtn.o
> ./a.out
4
--- end output ---
Comment 1 Richard Biener 2006-04-11 08:28:33 UTC
Confirmed.  The following aborts with -O2 and works with -O, optimized tree dumps are identical.

extern "C" void abort(void);
struct Test { char *p; };
inline void align(char* &p)
{
    ((long &)p) += 3;
    ((long &)p) &= -4;
}
int main()
{
    char buffer[8] = {0};
    Test t = { buffer };
    align(t.p);
    t.p += 4;
    align(t.p);
    t.p += 4;
    if (t.p - buffer != 8)
        abort();
}
Comment 2 Falk Hueffner 2006-04-11 09:40:22 UTC
It seems to me that t.p, which is of type char*, is accessed via an lvalue
of type long. So this is undefined behavior. Or am I missing something?
Comment 3 Pawel Sikora 2006-04-11 10:03:35 UTC
-O2 -fno-inline works (tested on x86-64).
Comment 4 Richard Biener 2006-04-11 10:33:35 UTC
Oh, right.  I was confused about 'char' and didn't see the alias violating.

*** This bug has been marked as a duplicate of 21920 ***