Re: [eigen] Alignment issues

[Nicola Gigante <nicola.gigante@xxxxxxxxx>]

Il giorno 14/feb/2014, alle ore 02:21, Christoph Hertzberg <chtz@xxxxxxxxxxxxxxxxxxxxxxxx> ha scritto:

> On 14.02.2014 01:14, Nicola Gigante wrote:
>> I would not trust ideone at all to deduce anything serious, so let’s
>> move to clang’s results...
> 
> We still want to support 32bit systems, which ideone appears to be using.
> 

Of course, nobody want to ditch 32bit systems...

>> In your test program, requesting an alignment of 128 bytes is asking
>> for troubles. The standard only guarantees support for alignment up
>> to alignof(std::max_align_t), which on OS X 64bits is 16.
> 
> If every malloc result is 16 byte aligned (on 64bit systems) anyways and the behavior of alignas is unspezified above 16 bytes, that means essentially alignas has no influence on new/new[]?
> Apparrently, on 32bit systems alignof(std::max_align_t) is 8 and malloc/new/new[] are 8byte aligned anywas ...

It’s not unspecified. Let me clarify a bit.

std::max_align_t is defined in [support.types] as:
"max_align_t is a POD type whose alignment requirement is at least as great as that of every scalar type, and whose alignment requirement is supported in every context.”
So alignof(std::max_align_t) is not at all the maximum alignment requirement supported. It’s just the bare minimum.

In [basic.align], an alignment requirement up to alignof(std::max_align_t) is called “fundamental alignment”. Alignments greater than that are “extended alignment”.
Types with extended alignment requirements are called “over-aligned types”.
Section [expr.new] defines behavior of operator new and says: "It is implementation-defined whether over-aligned types are supported”

Note that this doesn’t mean that, if you request an unsupported alignment, operator new can simply ignore it!
Rather, the program must not compile: 
"if the constant expression [in the alignas specifier] evaluates to an extended alignment and the implementation does not support that alignment in the context of the declaration, the program is ill-formed” from [dcl.align].

So if you’re requesting a 32bytes alignment and the program compiles, operator new must return a 32bytes aligned address. If not,
the compiler has a bug. So, again, I think it would be useful to make a mapping of behavior/bugs of actual compiler/arch/OS combinations.

Of course, nothing guarantees that C++11 alignas() semantics apply to the GNU and VC++ attributes, especially the guarantee that 
unsupported requirements gives to compilation errors. So it might be a win to use alignas() when supported, instead of the attributes,
to get precise guarantees (modulo bugs, again). Then in the documentation you can say “in C++11 mode we take care about alignment issues for you, unless you have a buggy compiler, in which case do as you would in C++98”.

If I find the time, I could setup a battery of virtual machines to make extensive comparisons.

> Christoph

Nicola