alignas and clang

[Thomas Stüfe]

The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.

----------------------------------------------------------------------
On Mon, Mar 6, 2023 at 5:23 PM Julian Waters <tanksherman27 at gmail.com>
wrote:

> 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.
>

Oh, you are right, I stopped reading before it got interesting.

"If the strictest (largest) alignas on a declaration is weaker than the
alignment it would have without any alignas specifiers (that is, weaker
than its natural alignment or weaker than alignas on another declaration of
the same object or type), the program is ill-formed."

Never mind then, I'll find a different solution.

Thanks for thinking this through with me!

Cheers,  Thomas

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/20230306/ec45bb46/attachment-0001.htm>