when compiling the attached gcc4bug.c with
$ gcc -Wall -O2 -fno-strict-aliasing gcc4bug.c -o gcc4bug;./gcc4bug ;echo $?
39
the assertion in line 39 gets triggered on ppc64, even though
-fno-strict-aliasing is used; looking at the assembler output, the 2 single-byte
stores (together with the assertion-checks before the call to _hexdump() that
got optimized away...) have been moved before the memcpy()
/* setting memory... */
#NO_APP
li 0,-54
ld 9,[EMAIL PROTECTED](2)
stb 0,120(1) // m_b
li 0,-2
nop
lhz 11,8(9)
lwz 10,0(9)
lwz 8,4(9)
stb 0,121(1) // m_c
sth 11,120(1)
stw 10,112(1)
stw 8,116(1)
#APP
/* done setting memory... */
interestingly, when enabling some of the commented out assert's in the .c file,
the code gets reordered to produce the expected result (i.e. all assertions to
hold, and the program to exit with a return code of 0)
(this behaviour wasn't present in gcc-3.4 yet)
$ gcc -v
Using built-in specs.
Target: powerpc64-linux
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr
--libexecdir=/usr/lib --enable-shared --with-system-zlib --enable-nls
--enable-threads=posix --without-included-gettext --program-suffix=-4.0
--enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gtk
--enable-mpfr --disable-nof --disable-softfloat --disable-werror
--enable-checking=release powerpc64-linux
Thread model: posix
gcc version 4.0.1 20050503 (prerelease) (Debian 4.0.0-2)
--
Summary: reordering/aliasing effect on ppc64
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: driver
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hvr at gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: powerpc64-linux
GCC host triplet: powerpc64-linux
GCC target triplet: powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21795
