You can try splitting Type.cpp into two files, put half the definitions into one file, see which file contains the miscomputed function, etc.

An 'interesting' result on that front: Depending on how I split the functions between the two new files, sometimes the assertions disappear entirely. Still figuring out which combination of functions being in the same translation unit causes it...

I split Type.cpp into two files. PointerType's constructor seems to be the culprit function, because moving it between the two files changes which object file needs to be replaced to fix the assertions. However, if it's in a file by itself, the assertions don't occur.

Right now, the minimal combination I found that causes failure is this, with just one other function definition in the file:

#include "LLVMContextImpl.h"
using namespace llvm;

void StructType::setBody(ArrayRef<Type*> Elements, bool isPacked) {
assert(isOpaque() && "Struct body already set!");

setSubclassData(getSubclassData() | SCDB_HasBody);
if (isPacked)
setSubclassData(getSubclassData() | SCDB_Packed);

Type *Elts = getContext().pImpl->
TypeAllocator.Allocate<Type>(Elements.size());
memcpy(Elts, Elements.data(), sizeof(Elements[0])*Elements.size());

ContainedTys = Elts;
NumContainedTys = Elements.size();
}

PointerType::PointerType(Type *E, unsigned AddrSpace)
: SequentialType(PointerTyID, E) {
setSubclassData(AddrSpace);
}

Okay... at that point, all you can really do is try to separate out an executable testcase that crashes from the rest of LLVM, and file a bug in the gcc or Ubuntu bug tracker...

Huh, I guess it's bitfield shenanigans going by this patch?

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20111226/134181.html

Yes, likely the same issue... did anyone actually file it against gcc, though?

PATCH
Guys, I fixed that. I posted it to llvm-commits. But it seems that it was deeply dived in posts ocean. So I repost it here:

The problem is in Type.h. The fields in Type class are declared in next
order:
TypeID ID : 8;
unsigned SubclassData : 24;
unsigned NumContainedTys;

Attempt to set new SubclassData value rewrites lowest byte in
NumContainedTys when -Os is set. GCC bug? Anyway setting SubclassData
with two workaround strings fixes the problem:

void setSubclassData(unsigned val) {
unsigned tmp = NumContainedTys; // Workaround for GCC -Os
SubclassData = val;
NumContainedTys = tmp; // Workaround for GCC -Os
// Ensure we don't have any accidental truncation.
assert(SubclassData == val && "Subclass data too large for field");
}

Probably there is another ways to protect NumContainedTys from overwritting?

Please find the patch in attachment for review.

-Stepan.

Yes, likely the same issue... did anyone actually file it against gcc, though?
I was goint to try and make a standalone single-file executable, but it's ridiculously complicated. So yeah, filed a bug with Ubuntu with the details for now:

https://bugs.launchpad.net/bugs/910363

Fixed in r147470

For the record, I just filed a bug with GCC:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51759