|Re: [eigen] Alignment issues|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] Alignment issues
- From: Nicola Gigante <nicola.gigante@xxxxxxxxx>
- Date: Fri, 14 Feb 2014 03:26:55 +0100
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=qn1uZqFwqJ4GaRMW+HUlnsl/57lAn36iCyLIMXJI3Fc=; b=PMsQmnqehA3axYvbOyteJzLcRGHoJlw0ap8opgblD8ohF0nJeIi7ya03z6f6RVAKYT spju3Y7rAMxmBzvqpEZZ0ErKdUPCfP+xMEqEE0QUYE9RIuG9A5khafCrNGbUk9J573JQ dC1MtDnQmV+Ssd9lErN6UqxaFBa0RnktRifVTrZx2z8wlvN2QTfcOl3BS/O0M6S+QLvR +cEAqIQ3yT/6xWczy3jkru3U9e1MlJLVtQhgM9v6JlbNFeoW33eesr0DyV6YphdFV2za iEEcIZ91YEGTOmkJFYX/pWDn0S31h/fk1dOgK41MPr3BsemQ7QoqyJK82z4NOjYDqXuT PLCA==
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.