On Tue, 1 Oct 2024 at 14:05, Frank Scheiner <frank.schei...@web.de> wrote: > > Hi Jonathan, > > On 01.10.24 11:28, Jonathan Wakely wrote: > > On Mon, 30 Sept 2024 at 18:26, Frank Scheiner wrote: > >> The following patch adds a workaround for this on the libstdc++ > >> testsuite side. > > > > Thanks for the patch. Please CC libstd...@gcc.gnu.org for all > > libstdc++ patches, as per https://gcc.gnu.org/lists.html > > Thanks for the hint, will do. I also spotted a small typo in the title > ("header" instead of "headers", as there are two glibc headers > involved), so I'll better send a V2 anyways. > > > 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. > > Is there > > software expecting to access those fields directly? > > Frankly, I have no idea. But I can run it through our toolchain > autobuilder (under CI on [2]) and in addition cross-build a T2 "base" > package selection ([3]) for ia64 with the changes included for "bits" > and "u" in the used glibc. The list of packages to be built is extensive > (as it also includes the "bootstrap" and "toolchain" lists). > > If we don't spot a problem there, we might never do. Give me a few days > for the latter, because I never did that so far and it'll require two > runs to be able to compare the results. > > [2]: http://epic-linux.org/ > > [3]: http://svn.exactcode.de/t2/trunk/target/generic/pkgsel/20-base.in > > 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.
