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

[Tim Northover via cfe-dev]

On 14 October 2015 at 16:06, Ed Maste <emaste at freebsd.org> wrote:
> On 14 October 2015 at 22:31, Tim Northover <t.p.northover at gmail.com> wrote:
> GCC says "This attribute specifies a minimum alignment (in bytes) for
> variables of the specified type." which implies to me the 16-byte ABI
> alignment should apply.

I think there might be two places discussing the attribute. One
applying to types, the other to variables (and typedefs, strangely).
>From https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html,
I'm basing my thoughts on:

"This attribute specifies a minimum alignment for the variable or
structure field, measured in bytes. [...] The default alignment is
fixed for a particular target ABI. [...] When used on a struct, or
struct member, the aligned attribute can only increase the alignment."

To me those 3 imply that attribute((aligned(N))) takes precedence over
the ABI and can reduce the alignment below ABI as long as it's not
applied to a struct. I take the "minimum" to mean that the compiler
isn't going to deliberately misalign a variable for you to guarantee
that "addr % (2*N) != 0".

> Perhaps this issue is _also_ a Clang bug. But if we assume the
> alignment attribute is a minimum, and we want the natural 8-byte
> alignment for ostream, libc++ is also in error.

I followed your reasoning on the aligned attribute (though still don't
agree), but I'm afraid I don't see this one. Are you saying that
libc++ should have used some other means to make sure that cout was
aligned to precisely 8 bytes, rather than 16? Should have known all
such attempts were futile and not tried, or what?

And how does this reasoning apply to other platforms where without the
attribute the ABI alignment would only have been 1?

Cheers.

Tim.