[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260313003705.GL1827@brightrain.aerifal.cx>
Date: Thu, 12 Mar 2026 20:37:05 -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: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.
Rich
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.
