[cfe-dev] libc++ std::cout alignment trouble (was: Re: [llvm] r240144 - [SLP] Vectorize for all-constant entries.)

[Tim Northover via llvm-commits]

> So there are two slightly different things here. I think we should be
> able to raise the alignment of global objects, independently of what the
> platform ABI says.

I'd like that to be the case, but it clearly is visible at shared
object boundaries so I don't think it's something we can change at
will.

> Now on the specific case of AMD64, there is a
> separate ABI rule which makes this a correct transform.

I don't think it does quite that. If you're applying that rule it
makes it a *necessary* transformation (in this view LLVM enforces ABI
alignments whether you want them or not for your language, LLVM 3.6
had a bug by not doing so, and trunk still has a bug for not always
doing so).

> The strange part is that noone seems to be observing this outside
> FreeBSD, which has a pretty ancient ld. What I don't know is where ld
> *is* picking up the 64bit alignment from.

ELF files don't actually contain an alignment field for symbols.
Gold's algorithm appears to start with the section's alignment, keep
reducing that until the symbol's address is properly aligned and then
decide that was "obviously" the intended alignment. Not ideal (objects
can easily get over-aligned by accident), but about the only sensible
way to do it given the data available.

So the 64-bit alignment ultimately came from LLVM only aligning the
section containing std::cout to 64-bits.

Tim.