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?
[1]:
https://gcc.gnu.org/git/?p=gcc.git;a=patch;h=cf5f7791056b3ed993bc8024be767a86157514a9
Cheers,
Frank
