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

[Richard Smith via cfe-dev]

On Sat, Oct 10, 2015 at 5:40 PM, Tim Northover via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> > 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.


Any chance this is because libc++ gives these objects different types in
the declaration versus the definition?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20151010/59fe7670/attachment.html>