[v2,01/10] ldbl-128ibm-compat: workaround C++ redirect limitations

  GCC 8+ 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.
---
 include/monetary.h |  8 ++++++++
 include/printf.h   |  8 ++++++++
 include/stdio.h    | 10 ++++++++++
 include/stdlib.h   |  9 +++++++++
 include/wchar.h    |  9 +++++++++
 5 files changed, 44 insertions(+)
  

On Fri, 27 Mar 2020, Paul E. Murphy via Libc-alpha wrote:

> GCC 8+ 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.

The first thing you need to include in the commit message for such a 
change is *the exact diagnostics you're trying to avoid*.  Only given 
those diagnostics can we try to work out a better fix.
  

On 3/27/20 4:34 PM, Joseph Myers wrote:
> On Fri, 27 Mar 2020, Paul E. Murphy via Libc-alpha wrote:
> 
>> GCC 8+ 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.

How about the following commit message body?

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.

Many errors of the following form appear:

In file included from ../include/sys/cdefs.h:3,
                  from ../include/features.h:465,
                  from ../bits/libc-header-start.h:33,
                  from ../math/math.h:27,
                  from ../include/math.h:7,
                  from test-math-isinff.cc:21:
../libio/bits/stdio-ldbl.h:25:20: error: declaration of ‘int 
sprintf(char*, const char*, ...)’ has a different exception specifier
    25 | __LDBL_REDIR_DECL (sprintf)
       |                    ^~~~~~~
../misc/sys/cdefs.h:461:26: note: in definition of macro ‘__LDBL_REDIR_DECL’
   461 |   extern __typeof (name) name __asm (__ASMNAME ("__" #name 
"ieee128"));
       |                          ^~~~
In file included from ../include/stdio.h:5,
                  from test-math-isinff.cc:22:
../libio/stdio.h:334:12: note: from previous declaration ‘int 
sprintf(char*, const char*, ...) throw ()’
   334 | extern int sprintf (char *__restrict __s,
       |            ^~~~~~~


> 
> The first thing you need to include in the commit message for such a
> change is *the exact diagnostics you're trying to avoid*.  Only given
> those diagnostics can we try to work out a better fix.
> 
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.
  

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).
  

On 4/1/20 6:07 PM, Joseph Myers wrote:
> 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).
> 

On second thought, this is surely a bug.  With some exploration, I found 
GCC PR 90731 fixed it between 9.2 and 9.3.  I will seek a lower bound 
and update the patch.