alignas and clang

[Julian Waters]

Ahhh, I see what you mean. Seems to me that this may actually be compiler
dependent, since C++14 simply states such situations are ill-formed and
makes no promises of instead choosing the larger alignment when
this happens. Does seem to be pretty annoying in that case :(

Love that pun though, on another note :P

best regards,
Julian

On Mon, Mar 6, 2023 at 11:52 PM Thomas Stüfe <thomas.stuefe at gmail.com>
wrote:

> Hi Julian,
>
> On Mon, Mar 6, 2023 at 4:22 PM Julian Waters <tanksherman27 at gmail.com>
> wrote:
>
>> Hi Thomas,
>>
>> From what I know gcc is actually the one that's not correct here, a
>> bigger alignment is considered stricter in C++ (though the Standard really
>> should make this much clearer) since a lower alignment value results in
>> more possible addresses, hence making the type's alignment weaker, and
>> alignas is very explicitly forbidden from weakening alignment, especially
>> the regular (unmodified) minimum alignment of said type.
>>
>
> gcc does not weaken the alignment, though. It just chooses whatever is
> larger: natural or explicitly given alignment. So it behaves to spec,
> provided I understand the spec.
>
> I don't know if there are places where we purposely weaken type alignment
>> in HotSpot though
>>
>
> Not weaken, and not purposefully. But the specified alignment may be
> smaller than the natural one, and the natural (hah) thing to do would be to
> choose whatever's larger.
>
> For example, from https://github.com/openjdk/jdk/pull/12879:
>
> template <class T> struct MyContainer {
>   union alignas(alignof(T)) DataHolder {
>     char bytes[sizeof(T)];
>     void* p;
>   };
>   DataHolder d;
> };
>
> So, I want the compiler to allocate storage aligned for T, but postpone
> the actual construction of T. I also want to keep the thing in a freelist,
> hence the next pointer (here its a union, but that does not matter for the
> problem).
>
> For T=int, on 64-bit, I would have expected the compiler to generate
> DataHolder with an alignment requirement of 8 since T needs 4 and void*
> needs 8. But the compiler does not accept this. However, clang accepts
> ATTRIBUTE_ALIGNED and then does what gcc does.
>
> Cheers, Thomas
>
>
>> best regards,
>> Julian
>>
>> On Mon, Mar 6, 2023 at 10:19 PM Thomas Stüfe <thomas.stuefe at gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> I'm not sure if this has been discussed before. With alignas, on clang,
>>> if the natural type of the data has a larger alignment than what I
>>> requested with alignas, I get a compile error if the specified alignment is
>>> smaller than what would be the natural alignment of the type.
>>>
>>> Example:
>>>
>>> struct alignas(2) XX {
>>>   void* p;
>>> };
>>>
>>> gives: error: requested alignment is less than minimum alignment of 8
>>> for type 'XX'
>>>
>>> Happens on both MacOS and Linux clang build. Does not happen with GCC.
>>> Does not happen with ATTRIBUTE_ALIGN(2).
>>>
>>> Is this a clang bug? The standard [1] says:
>>>
>>> "The object or the type declared by such a declaration will have its
>>> alignment requirement equal to the strictest (largest) non-zero expression
>>> of all alignas specifiers used in the declaration, unless it would weaken
>>> the natural alignment of the type. "
>>>
>>> That reads to me like gcc is correct.
>>>
>>> This is a bit of a drawback compared to ATTRIBUTE_ALIGN, especially if
>>> coding for different 32-bit and 64-bit platforms.
>>>
>>> [1] https://en.cppreference.com/w/cpp/language/alignas
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-dev/attachments/20230307/a6c61fcd/attachment-0001.htm>