public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Joseph Myers <joseph@codesourcery.com>
To: Paul E Murphy <murphyp@linux.ibm.com>
Cc: <libc-alpha@sourceware.org>
Subject: Re: [PATCH v2 01/10] ldbl-128ibm-compat: workaround C++ redirect limitations
Date: Wed, 1 Apr 2020 23:07:12 +0000	[thread overview]
Message-ID: <alpine.DEB.2.21.2004012301310.3007@digraph.polyomino.org.uk> (raw)
In-Reply-To: <cca5403b-c2e0-7fad-cd28-775b4c5759e4@linux.ibm.com>

On Wed, 1 Apr 2020, Paul E Murphy via Libc-alpha wrote:

> GCC 9.2 is more pedantic about type checking the redirect declarations
> for non-system headers.  I am not sure if there is less obtrusive way
> to dodge these warnings when building C++ tests using the headers from
> the glibc under construction.

Warnings about inconsistency of attributes for aliases were addressed by 
using __attribute_copy__ in alias macros.  Those warnings typically 
indicated that code using the aliases would be suboptimal in some way (not 
fully optimized based on attributes, or with diagnostics based on those 
attributes potentially missing).

This seems like something similar, but about C++ exception specifications 
instead of attributes.  If there isn't some way to copy exception 
specifications, maybe there needs to be a variant of __LDBL_REDIR_DECL 
where attributes / exception specifications / ... can be passed in 
explicitly.  Then you can include __THROWNL in that call to 
__LDBL_REDIR_DECL and similarly for all other such redirected functions 
where __THROWNL is part of the declaration of the original function.

> I noticed this occurs on FSF GCC 9.2, but not 9.3 and newer.  The
> documentation is vague about which warnings and errors are disabled by
> system_header pragma.

Or if it's a GCC bug it would be useful to identify exactly which bug in 
GCC Bugzilla it is / which commit fixed it (and potentially have a 
workaround that is explicitly conditioned on the buggy GCC versions with a 
comment referencing the exact bug and fixed versions).

-- 
Joseph S. Myers
joseph@codesourcery.com

  parent reply	other threads:[~2020-04-01 23:07 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-27 21:17 [PATCH v2 00/10] IEEE binary128 long double on powerpc64le Paul E. Murphy
2020-03-27 21:17 ` [PATCH v2 01/10] ldbl-128ibm-compat: workaround C++ redirect limitations Paul E. Murphy
2020-03-27 21:34   ` Joseph Myers
2020-04-01 20:29     ` Paul E Murphy
2020-04-01 20:41       ` DJ Delorie
2020-04-01 23:07       ` Joseph Myers [this message]
2020-04-02 16:48         ` Paul E Murphy
2020-03-27 21:17 ` [PATCH v2 02/10] ldbl-128ibm: simplify iscanonical.h Paul E. Murphy
2020-04-03 20:12   ` Tulio Magno Quites Machado Filho
2020-04-06 16:46     ` Paul E Murphy
2020-03-27 21:17 ` [PATCH v2 03/10] Rename __LONG_DOUBLE_USES_FLOAT128 to Paul E. Murphy
2020-04-03 19:22   ` Tulio Magno Quites Machado Filho
2020-03-27 21:17 ` [PATCH v2 04/10] powerpc64le: Enforce -mabi=ibmlongdouble when -mfloat128 used Paul E. Murphy
2020-04-03 19:29   ` Tulio Magno Quites Machado Filho
2020-04-06 16:49     ` Paul E Murphy
2020-03-27 21:17 ` [PATCH v2 05/10] powerpc64le: workaround ieee long double / _Float128 stdc++ bug Paul E. Murphy
2020-04-03 19:03   ` Tulio Magno Quites Machado Filho
2020-03-27 21:17 ` [PATCH v2 06/10] powerpc64le: raise GCC requirement to 7.3 for long double transition Paul E. Murphy
2020-03-31 20:47   ` Paul E Murphy
2020-03-27 21:17 ` [PATCH v2 07/10] powerpc64le: bump binutils version requirement to >= 2.26 Paul E. Murphy
2020-04-03 19:36   ` Tulio Magno Quites Machado Filho
2020-03-27 21:17 ` [PATCH v2 08/10] powerpc64le: enforce non-specific long double in .gnu.attributes section Paul E. Murphy
2020-04-03 19:49   ` Tulio Magno Quites Machado Filho
2020-03-27 21:18 ` [PATCH v2 09/10] powerpc64le: blacklist broken GCC compilers (e.g GCC 7.5.0) Paul E. Murphy
2020-04-03 20:38   ` Adhemerval Zanella
2020-04-07 19:57     ` Paul E Murphy
2020-03-27 21:18 ` [PATCH v2 10/10] powerpc64le: Enable support for IEEE long double Paul E. Murphy

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=alpine.DEB.2.21.2004012301310.3007@digraph.polyomino.org.uk \
    --to=joseph@codesourcery.com \
    --cc=libc-alpha@sourceware.org \
    --cc=murphyp@linux.ibm.com \
    /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: link
Be 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).