On Thu, 17 Sep 2020, clyon at gcc dot gnu.org wrote:

> This happens because the testcase does
> #define x (
> and "x" is used as parameter names in several function prototypes in newlib's
> math.h

That's a bug in newlib, which should be fixed there.

(In reply to joseph@codesourcery.com from comment #1)
> On Thu, 17 Sep 2020, clyon at gcc dot gnu.org wrote:
> 
> > This happens because the testcase does
> > #define x (
> > and "x" is used as parameter names in several function prototypes in newlib's
> > math.h
> 
> That's a bug in newlib, which should be fixed there.

OK, so you mean that prototypes like
extern int __isinff (float x);
should not name their parameters? I can certainly submit the simple patch to newlib.

Regarding the problem with glibc, the problem is in ucontext.h, where struct _libc_fpstate is declared as:
struct _libc_fpstate
{
  struct
  {
    unsigned int sign1:1;
    unsigned int unused:15;
    unsigned int sign2:1;
    unsigned int exponent:14;
    unsigned int j:1;
    unsigned int mantissa1:31;
    unsigned int mantissa0:32;
  } fpregs[8];
  unsigned int fpsr:32;
  unsigned int fpcr:32;
  unsigned char ftype[8];
  unsigned int init_flag;
};

The offending field is 'j', because libstdc++'s 17_intro/names.cc defines 'j' as '('. Do you mean that field should also be renamed? That sounds odd.

(In reply to Christophe Lyon from comment #2)
> OK, so you mean that prototypes like
> extern int __isinff (float x);
> should not name their parameters? I can certainly submit the simple patch to
> newlib.

The parameter should use a reserved name, e.g. __x.

This is a valid C program which will presumably fail to compile with newlib:

#define x 1234
#include <math.h>
int main() { return 0; }

The point of the test is to ensure that libstdc++ headers don't use non-reserved names like 'x'. In this case it's found a newlib bug, not a libstdc++ one.

The glibc case is a bit more complicated. 'j' is not a reserved name, but (at least on x86) the __libc_fpstate types do use reserved names unless __USE_MISC is defined. In strict modes a reserved name like __j will be used intead. Maybe the test needs to account for that.

<asm/types.h> also has this on ppc linux:

typedef struct { 
        __u32 u[4];
} __attribute__((aligned(16))) __vector128;

*** Bug 101211 has been marked as a duplicate of this bug. ***

This now happens even without --disable-libstdcxx-pch because in r12-1742 I added

{ dg-add-options no_pch }

which means the PCH headers aren't used for the test.

The master branch has been updated by Jonathan Wakely <redi@gcc.gnu.org>:

https://gcc.gnu.org/g:e83a5a6b6893e910dc0b6b1cd034e1a258406c93

commit r12-1814-ge83a5a6b6893e910dc0b6b1cd034e1a258406c93
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Fri Jun 25 18:31:22 2021 +0100

    libstdc++: More workarounds in 17_intro/names.cc test [PR 97088]
    
    Conditionally #undef some more names that are used in system headers.
    
    libstdc++-v3/ChangeLog:
    
            PR libstdc++/97088
            * testsuite/17_intro/names.cc: Undef more names for newlib and
            also for arm-none-linux-gnueabi.
            * testsuite/experimental/names.cc: Disable PCH.

The master branch has been updated by Jonathan Wakely <redi@gcc.gnu.org>:

https://gcc.gnu.org/g:75f948f089ceb8888fd00913635264e20610d0f2

commit r12-1845-g75f948f089ceb8888fd00913635264e20610d0f2
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Mon Jun 28 15:13:34 2021 +0100

    libstdc++: Fix backwards logic in 17_intro/names.cc test [PR 97088]
    
    I meant to undef the names that clash with newlib headers for newlib,
    but I only undef'd them for non-newlib targets. This means they still
    cause errors for newlib, and aren't tested for other targets.
    
    This fixes the test to check those names for non-newlib targets, and to
    undef them to avoid errors for newlib.
    
    libstdc++-v3/ChangeLog:
    
            PR libstdc++/97088
            * testsuite/17_intro/names.cc: Fix #if condition for names used
            by newlib headers.