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
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...
Cheers,
Frank
