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

[Dimitry Andric via cfe-dev]

On 15 Oct 2015, at 00:31, Tim Northover <t.p.northover at gmail.com> wrote:
> 
>>> It's impossible to do otherwise (and maintain our cunning lazy
>>> initialization). Other places are using std::cout as an ostream, which
>>> has an ABI-required alignment of (at least) 8.
> 
> First, Joerg pointed out on IRC that my statement above was in error
> and the ABI-alignment of "char cout[LOTS]" is actually 16, which means
> that on AMD64 only we could have skipped the aligned attribute. I
> don't think that affects what we do here though.
> 
>> I'm a bit confused about where the bug actually is though. As I
>> understand it, the alignment attribute specifies the minimum
>> alignment, and the cunning char array trick actually imposes a 16-byte
>> ABI alignment.
> 
> So the AMD64 ABI alignment should override the attribute? I think
> Dmitri has a good point that that's not how GCC interprets it (even
> the documentation seems to allow under-aligning non-struct variables).
> But even if so the bug would be in Clang 3.6[*] for emitting that
> declaration into libc++.so with only 8 bytes alignment.
> 
> We'd also still have the issue that we probably shouldn't overalign
> externally visible globals on ELF, even if the AMD64 ABI came to the
> rescue in this one case.
> 
> My summary position is:
> 1. We need to stop over-aligning externally visible globals on ELF.
> Ideally only if they're going into a shared library, but I don't think
> that info is available.
> 2. "align 8" is correct for a "__attribute__((aligned(8))) char
> arr[LOTS]" declaration.

This thread unfortunately died out without any resolution, so we are now
nearing 3.8 branching, and the problem is still not fixed.  E.g., the
only custom patch we have now left in FreeBSD's version of llvm (which
we would really like to get rid of!) is the reversal of r240144: it is a
pretty gross workaround, but it works for now.

But is there any way that we can get this resolved before 3.8.0 ships,
please? :-)

-Dimitry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 194 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20151231/6c2abdbb/attachment.sig>