On Fri, 14 Jun 2024 at 14:07, Frank Scheiner <frank.schei...@web.de> wrote:
>
> On 14.06.24 14:53, Jonathan Wakely wrote:
> > On Fri, 14 Jun 2024 at 12:07, Frank Scheiner <frank.schei...@web.de> wrote:
> >> ...point to two headers which are part of glibc 2.39 (w/ia64 support
> >> re-added):
> >>
> >> * /usr/include/bits/sigcontext.h:32-38:
> >> ```
> >> 32 struct __ia64_fpreg
> >> 33 {
> >> 34 union
> >> 35 {
> >> 36 unsigned long bits[2];
> >> 37 } u;
> >> 38 } __attribute__ ((__aligned__ (16)));
> >> ```
> >>
> >> * /usr/include/sys/ucontext.h:39-45:
> >> ```
> >> 39 struct __ia64_fpreg_mcontext
> >> 40 {
> >> 41 union
> >> 42 {
> >> 43 unsigned long __ctx(bits)[2];
> >> 44 } __ctx(u);
> >> 45 } __attribute__ ((__aligned__ (16)));
> >> ```
> >
> > This is an ia64-specific glibc bug, because it means the following
> > valid C program is rejected:
> >
> > #define _GNU_SOURCE
> > #define bits 111
> > #define u no u
> > #include <signal.h>
> > int main() { }
>
> Ok, I see. Should this then be "worked around" like in [1] with
> something like:
>
> ```
> #if defined (__linux__) && defined (__ia64__)
> // <sys/ucontext.h> defines __ia64_fpreg_mcontext::u
> #undef u
> #endif
> ```
>
> ...in `libstdc++-v3/testsuite/17_intro/names.cc` or should we fix it in
> glibc instead?
Both, ideally. The libstdc++ test should definitely be fixed because
it fails with released versions of glibc already in the wild. But
glibc should also be fixed because it's a standards conformance issue.
>
> [1]:
> https://gcc.gnu.org/git/?p=gcc.git;a=patch;h=cf5f7791056b3ed993bc8024be767a86157514a9
>
> Cheers,
> Frank
>
