[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260313012418.GM1827@brightrain.aerifal.cx>
Date: Thu, 12 Mar 2026 21:24:18 -0400
From: Rich Felker <dalias@...c.org>
To: James Y Knight <jyknight@...gle.com>
Cc: musl@...ts.openwall.com, Xing Li <lixing@...ngson.cn>,
wanghongliang@...ngson.cn
Subject: Re: [PATCH] loongarch64: Add lsx and lasx regset definition
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
View attachment "0001-loongarch64-add-lsx-and-lasx-regset-definition.patch" of type "text/plain" (816 bytes)
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.
