public inbox for libstdc++-cvs@sourceware.org help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@gcc.gnu.org> To: gcc-cvs@gcc.gnu.org, libstdc++-cvs@gcc.gnu.org Subject: [gcc r13-5461] libstdc++: Fix up FAIL in 17_intro/names.cc on glibc < 2.19 [PR108568] Date: Fri, 27 Jan 2023 19:13:43 +0000 (GMT) [thread overview] Message-ID: <20230127191343.8C6AD3858D20@sourceware.org> (raw) https://gcc.gnu.org/g:815e5740162d2d0b7b54031f72c201065016d58c commit r13-5461-g815e5740162d2d0b7b54031f72c201065016d58c Author: Jakub Jelinek <jakub@redhat.com> Date: Fri Jan 27 20:11:20 2023 +0100 libstdc++: Fix up FAIL in 17_intro/names.cc on glibc < 2.19 [PR108568] On gcc112 which has glibc 2.17 I've noticed FAIL: 17_intro/names.cc (test for excess errors) FAIL: experimental/names.cc (test for excess errors) These are because glibc < 2.19 used __unused as field member of various structs, including mcontext_t in sys/ucontext.h on ppc64le. This was changed in glibc with https://gcc.gnu.org/pipermail/libc-alpha/2013-November/045766.html names.cc even has #ifdef __GLIBC_PREREQ #if ! __GLIBC_PREREQ(2, 19) // Glibc defines this prior to 2.19 #undef __unused #endif #endif for it, but it doesn't work. The reason is that __GLIBC_PREREQ is defined in <features.h> but nothing included that header before this spot (it is included later from bits/stdc++.h). The following patch on Linux/Hurd conditionally includes features.h to get the needed macros before deciding if __unused should be undefined or not. If needed, I could use __GLIBC_PREREQ then but would need to check if it is defined and between 1996 and 1999 it wasn't. 2023-01-27 Jakub Jelinek <jakub@redhat.com> PR libstdc++/108568 * testsuite/17_intro/names.cc (__unused): For linux or GNU hurd include features.h if present and then check __GLIBC__ and __GLIBC_MINOR__ macros for glibc prior to 2.19, instead of testing __GLIBC_PREREQ which isn't defined yet. Diff: --- libstdc++-v3/testsuite/17_intro/names.cc | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/libstdc++-v3/testsuite/17_intro/names.cc b/libstdc++-v3/testsuite/17_intro/names.cc index 6fe9350aec6..d3e0db9bab6 100644 --- a/libstdc++-v3/testsuite/17_intro/names.cc +++ b/libstdc++-v3/testsuite/17_intro/names.cc @@ -252,12 +252,15 @@ #undef y #endif -#ifdef __GLIBC_PREREQ -#if ! __GLIBC_PREREQ(2, 19) +#if defined (__linux__) || defined (__gnu_hurd__) +#if __has_include(<features.h>) +#include <features.h> +#if __GLIBC__ == 2 && __GLIBC_MINOR__ < 19 // Glibc defines this prior to 2.19 #undef __unused #endif #endif +#endif #if __has_include(<newlib.h>) // newlib's <sys/cdefs.h> defines these as macros.
reply other threads:[~2023-01-27 19:13 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20230127191343.8C6AD3858D20@sourceware.org \ --to=jakub@gcc.gnu.org \ --cc=gcc-cvs@gcc.gnu.org \ --cc=libstdc++-cvs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).