Compiling the attached preprocessed file with this: g++-4.5 -Os -fPIC -g -pedantic -Wno-long-long -fno-exceptions -o Type2.cpp.o -c Type2.ii Results in writing 32 bits to a 24-bit bitfield, overwriting the first byte of the next member variable. These two members of class Type are (on x86_64) at offset 0x8: TypeID ID : 8; unsigned SubclassData : 24; When setSubclassData() isn't inlined, it's called (from StructType::setBody() and PointerType's constructor) with the address of 'SubclassData' in %rdi...: 0x00007ffff76d684f <+71>: lea 0x9(%rdi),%r12 0x00007ffff76d6853 <+75>: or $0x1,%esi 0x00007ffff76d6856 <+78>: mov %r12,%rdi 0x00007ffff76d6859 <+81>: callq 0x7ffff76d6774 <llvm::Type::setSubclassData(unsigned int)> ...but then, setSubclassData writes more than 24 bits to that address: 0x00007ffff76d6774 <+0>: mov %esi,%eax 0x00007ffff76d6776 <+2>: sub $0x8,%rsp 0x00007ffff76d677a <+6>: and $0xffffff,%eax 0x00007ffff76d677f <+11>: cmp %esi,%eax 0x00007ffff76d6781 <+13>: mov %eax,(%rdi) # corruption
Created attachment 26244 [details] output of `gcc -v -save-temps`
Created attachment 26245 [details] pre-processed file (gzip-compressed)
It's a bug in IPA-SRA that creates non-mode-size stores: void llvm::Type::_ZN4llvm4Type15setSubclassDataEj.clone.1(unsigned int:24*, unsigned int) (<unnamed-unsigned:24> * ISRA.6, unsigned int val) { ... <bb 2>: D.87358_2 = (<unnamed-unsigned:24>) val_1(D); *ISRA.6_8(D) = D.87358_2; I think this has been fixed in 4.6 (not on the 4.5 branch though) which no longer performs this substitution. You can work around this using -fno-ipa-sra. The following is a simplified testcase: extern "C" void abort (void); struct S { void __attribute__((noinline)) set(unsigned val) { data = val; if (data != val) abort (); } int pad0; unsigned pad1 : 8; unsigned data : 24; int pad2; }; int main() { S s; s.pad2 = -1; s.set(0); if (s.pad2 != -1) abort (); } Where 4.6 says: Candidate (2069): this ! Disqualifying this - Encountered a bit-field access. which hints at what needs backporting. Martin?
(In reply to comment #3) > Where 4.6 says: > > Candidate (2069): this > ! Disqualifying this - Encountered a bit-field access. > > which hints at what needs backporting. > > Martin? Right, this seems to be PR 45644, for some reason I did not backport the fix to 4.5. It should be fixed by committing http://gcc.gnu.org/viewcvs?view=revision&revision=164313 I'll do the backport and test it today.
Patch backporting the fix has been posted to the mailing list: http://gcc.gnu.org/ml/gcc-patches/2012-01/msg00300.html
Author: jamborm Date: Mon Jan 9 18:40:09 2012 New Revision: 183023 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183023 Log: 2012-01-09 Martin Jambor <mjambor@suse.cz> PR tree-optimization/51759 Backport from mainline 2010-09-15 Martin Jambor <mjambor@suse.cz> PR middle-end/45644 * tree-sra.c (create_access): Check for bit-fields directly. * testsuite/gcc.dg/ipa/pr45644.c: New test. * testsuite/g++.dg/ipa/pr51759.C: Likewise. Added: branches/gcc-4_5-branch/gcc/testsuite/g++.dg/ipa/pr51759.C branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/ipa/pr45644.c Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/testsuite/ChangeLog branches/gcc-4_5-branch/gcc/tree-sra.c
Author: jamborm Date: Mon Jan 9 19:52:06 2012 New Revision: 183029 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183029 Log: 2012-01-09 Martin Jambor <mjambor@suse.cz> PR tree-optimization/51759 * g++.dg/ipa/pr51759.C: New test. Added: trunk/gcc/testsuite/g++.dg/ipa/pr51759.C Modified: trunk/gcc/testsuite/ChangeLog
Author: jamborm Date: Mon Jan 9 20:03:08 2012 New Revision: 183031 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183031 Log: 2012-01-09 Martin Jambor <mjambor@suse.cz> PR tree-optimization/51759 * g++.dg/ipa/pr51759.C: New test. Added: branches/gcc-4_6-branch/gcc/testsuite/g++.dg/ipa/pr51759.C Modified: branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
I have backported the fix to the 4.5 branch and also committed the testcase to the the 4.6 branch and trunk. Still it is a duplicate of PR 45644 and so I'm closing this as such. *** This bug has been marked as a duplicate of bug 45644 ***