Bug 27241 - Bad code reordering when using an enum as a bitfield
Summary: Bad code reordering when using an enum as a bitfield
Status: RESOLVED DUPLICATE of bug 21920
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 3.4.5
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-04-21 23:02 UTC by Dan Bornstein
Modified: 2006-04-23 20:41 UTC (History)
59 users (show)

See Also:
Host:
Target: arm-elf
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments
Source file that demonstrates the bug (234 bytes, text/plain)
2006-04-21 23:04 UTC, Dan Bornstein
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Dan Bornstein 2006-04-21 23:02:55 UTC
I have an example in which it looks like code is reordered improperly. The bug seems to be triggered by using an enumerated type in a bitfield. I found the bug compiling for arm-elf, but I have reports that it fails in a similar way compiling for x86 (Linux).

Here's the compile command I used and its output:

$ g++ -save-temps -v -march=armv5te -fpic -g -O2 -S shorty.cpp

Reading specs from /usr/local/armdev-051213/lib/gcc/arm-elf/3.4.5/specs
Configured with: ../gcc-3.4.5/configure --prefix=/usr/local/armdev-051213 --target=arm-elf --enable-languages=c,c++ --enable-threads --disable-nls --enable-multilib --with-float=soft --without-fp
Thread model: single
gcc version 3.4.5
 /usr/local/armdev-051213/libexec/gcc/arm-elf/3.4.5/cc1plus -E -quiet -v -iprefix /usr/local/armdev-051213/arm-elf/bin/../lib/gcc/arm-elf/3.4.5/ -D__ARM_ARCH_5TE__ -D__USES_INITFINI__ shorty.cpp -march=armv5te -msoft-float -fpic -fworking-directory -O2 -o shorty.ii
ignoring nonexistent directory "/usr/local/armdev-051213/arm-elf/bin/../lib/gcc/arm-elf/3.4.5/../../../../include/c++/3.4.5"
ignoring nonexistent directory "/usr/local/armdev-051213/arm-elf/bin/../lib/gcc/arm-elf/3.4.5/../../../../include/c++/3.4.5/arm-elf"
ignoring nonexistent directory "/usr/local/armdev-051213/arm-elf/bin/../lib/gcc/arm-elf/3.4.5/../../../../include/c++/3.4.5/backward"
ignoring nonexistent directory "/usr/local/armdev-051213/arm-elf/bin/../lib/gcc/arm-elf/3.4.5/include"
ignoring nonexistent directory "/usr/local/armdev-051213/arm-elf/bin/../lib/gcc/arm-elf/3.4.5/../../../../arm-elf/sys-include"
ignoring nonexistent directory "/usr/local/armdev-051213/arm-elf/bin/../lib/gcc/arm-elf/3.4.5/../../../../arm-elf/include"
ignoring nonexistent directory "/usr/local/armdev-051213/lib/gcc/arm-elf/3.4.5/../../../../include/c++/3.4.5"
ignoring nonexistent directory "/usr/local/armdev-051213/lib/gcc/arm-elf/3.4.5/../../../../include/c++/3.4.5/arm-elf"
ignoring nonexistent directory "/usr/local/armdev-051213/lib/gcc/arm-elf/3.4.5/../../../../include/c++/3.4.5/backward"
ignoring nonexistent directory "/usr/local/armdev-051213/lib/gcc/arm-elf/3.4.5/../../../../arm-elf/sys-include"
ignoring nonexistent directory "/usr/local/armdev-051213/lib/gcc/arm-elf/3.4.5/../../../../arm-elf/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/armdev-051213/lib/gcc/arm-elf/3.4.5/include
End of search list.
 /usr/local/armdev-051213/libexec/gcc/arm-elf/3.4.5/cc1plus -fpreprocessed shorty.ii -quiet -dumpbase shorty.cpp -march=armv5te -msoft-float -auxbase shorty -g -O2 -version -fpic -o shorty.s
GNU C++ version 3.4.5 (arm-elf)
        compiled by GNU C version 4.0.1 (Apple Computer, Inc. build 5247).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Comment 1 Dan Bornstein 2006-04-21 23:04:11 UTC
Created attachment 11315 [details]
Source file that demonstrates the bug

Compile this file as indicated in the original bug report, and then examine the resulting source file.
Comment 2 Andrew Pinski 2006-04-21 23:06:56 UTC
You are violating C/C++ aliasing rules:
  Length(const Length &o) { *((unsigned int *)this) = *((unsigned int *)&o); }

Use either -fno-strict-aliasing or use memcpy but even then that might not work as this is a non-POD.

*** This bug has been marked as a duplicate of 21920 ***
Comment 3 Dan Bornstein 2006-04-21 23:11:47 UTC
Wow, that was quick.