On Tue, 1 Oct 2024 at 16:53, Frank Scheiner <frank.schei...@web.de> wrote: > > Hi Jonathan, Joseph, > > On 01.10.24 15:32, Jonathan Wakely wrote: > > On Tue, 1 Oct 2024 at 14:05, Frank Scheiner <frank.schei...@web.de> wrote: > >> On 01.10.24 11:28, Jonathan Wakely wrote: > >>> On Mon, 30 Sept 2024 at 18:26, Frank Scheiner wrote: > >>> It looks like the glibc header also defines "bits" without using the > >>> implementation namespace. Is there a reason the re-added ia64 code in > >>> the glibc header can't be fixed to use __bits and __u? > >> > >> No, I think we can do that. As it only affects C++ you proposed in [1] > >> to "just change the libstdc++ tests" though. > >> > >> [1]: https://gcc.gnu.org/pipermail/gcc-patches/2024-June/654889.html > > > > Ah yes. I think the sys/ucontext.h case only affects C++ (and C when > > _GNU_SOURCE is defined), but the sys/sigcontext.h case affects C too. > > Both 'u' and 'bits' are used without the __ctx macro. > > I looked at the error messages for the tests ([2]) again and for 'u', > even when used with the __ctx macro in "ucontext.h", it seems to be an > issue: > > ``` > [...] > compiler exited with status 1 > FAIL: 17_intro/names.cc -std=gnu++17 (test for excess errors) > Excess errors: > /usr/include/bits/sigcontext.h:37: error: expected unqualified-id before > ';' token > /usr/include/bits/sigcontext.h:37: error: expected ')' before ';' token > /usr/include/sys/ucontext.h:44: error: expected unqualified-id before > ';' token > /usr/include/sys/ucontext.h:44: error: expected ')' before ';' token > [...] > ```by > > [2]: > https://gcc.gnu.org/pipermail/gcc-patches/attachments/20240614/880a99c1/attachment-0001.md > > Though I don't understand why. From the error message it sounds like 'u' > was replaced with '(' before the __ctx macro could do its job. > > But Joseph also wrote that it "prepends __ in standards conformance > modes" in [3]. And this might not be the case for these specific tests, > so the __ctx macro might not have any effect here.
It has no effect here. G++ unconditionally defines _GNU_SOURCE which means the __ctx macro does nothing. > > [3]: https://gcc.gnu.org/pipermail/gcc-patches/2024-June/654883.html > > BTW, the two glibc headers are available here for reference: > > * > https://github.com/linux-ia64/glibc-ia64/blob/release/2.39/master-w-ia64/sysdeps/unix/sysv/linux/ia64/bits/sigcontext.h > > * > https://github.com/linux-ia64/glibc-ia64/blob/release/2.39/master-w-ia64/sysdeps/unix/sysv/linux/ia64/sys/ucontext.h > > ...names.cc here: > > https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/testsuite/17_intro/names.cc;h=9b0ffcb50b2e07a5ff2c2bd480b9eecd402c78d3;hb=HEAD > > >> IIUC, if those changes in the glibc don't bite us, this patch here can > >> be dropped again, right? OTOH it seems to be like that in the glibc > >> since a while, so the gcc/libstdc++ patch could be kept for builds > >> against older glibc versions anyway. But let's first see what will > >> happen... > > > > > > I think we can change the libstdc++ test anyway, so it PASSes whether > > or not any change happens for glibc. > > Agreed. > > Cheers, > Frank >
