[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <3dec172f-fec8-b8f9-cb83-0b9c761dc943@loongson.cn>
Date: Fri, 13 Mar 2026 10:52:59 +0800
From: lixing <lixing@...ngson.cn>
To: musl@...ts.openwall.com, Rich Felker <dalias@...c.org>,
James Y Knight <jyknight@...gle.com>
Cc: wanghongliang@...ngson.cn
Subject: Re: [PATCH] loongarch64: Add lsx and lasx regset definition
在 2026/3/13 上午9:24, Rich Felker 写道:
> On Thu, Mar 12, 2026 at 08:37:05PM -0400, Rich Felker wrote:
>> On Thu, Mar 12, 2026 at 08:35:43PM -0400, Rich Felker wrote:
>>> On Thu, Mar 12, 2026 at 03:09:59PM -0400, James Y Knight wrote:
>>>> On Wed, Mar 11, 2026 at 12:24 PM Rich Felker <dalias@...c.org> wrote:
>>>>> I'm not sure how GNU C __attribute__((__aligned__(...))) even binds,
>>>>> which is part of why I don't like it and prefer the clearer ISO C
>>>>> form.
>>>> The rules for where GNU C attributes are indeed somewhat tricky. But
>>>> in this case: the original was applied to the typedef (the entity
>>>> immediately to the left), and in my first suggestion, it applied to
>>>> the union type (again, the entity immediately to the left).
>>>>
>>>>>> typedef union
>>>>>> {
>>>>>> _Alignas(16) double d[2];
>>>>>> _Alignas(16) float f[4];
>>>>>> } elf_lsxregset_t[32];
>>>>> Does that work? Or would that be trying to apply the alignment to
>>>>> double where the alignment is larger than the type and thereby
>>>>> invalid? This is totally on me, but I don't understand well how the
>>>>> binding works.
>>>> Yep, it works. And the standard rules are quite simple: in C, alignas
>>>> may _only_ be applied to structure fields or local/global variables --
>>>> not to types (or parts of types), at all. In C++, it may also be
>>>> applied to an entire struct/class/union, so, e.g. `struct alignas(64)
>>>> Foo { int x; };` is valid only in C++. Neither standard permits it to
>>>> be applied to a typedef, or other such "interesting" usage.
>>> OK, sounds good. However, I think I'll just take the patch as-is for
>>> now. Using _Alignas would require some refactoring work to make it
>>> available in pre-C11 context via features.h or whatever rather than
>>> depending on stdalign.h which we can't include here. And that in turn
>>> would require consideration of whether there are any bad consequences
>>> of mismatched semantics between _Alignas and the GNUC stuff.
>>>
>>> Hopefully we can clean this up sometime after release.
>> Hmm, maybe we could just go ahead and put the
>> __attribute__((__aligned__(...))) inside the struct now tho? That
>> would at least avoid the dependency on it applying to the typedef in a
>> confusing way that mismatches the C behavior.
> Is this ok?
>
> BTW, I was thinking this was in signal.h, where this stuff would
> matter more. user.h is pretty much only for gdb and similar, so it's
> probably not worth spending much effort on making it "nice".
>
> Rich
Thanks, that's ok.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
