Re: Preventing ISO C errors when using macros for builtin types

[Jozef Lawrynowicz <jozefl dot gcc at gmail dot com>]

On Wed, 5 Jun 2019 11:49:21 -0500
Segher Boessenkool <segher@kernel.crashing.org> wrote:

> On Wed, Jun 05, 2019 at 02:25:59PM +0100, Jozef Lawrynowicz wrote:
> > I'm assuming it would not be valid to modify the behaviour of __extension__
> > so it can be placed within a declaration, and not just at the
> > beginning. However, there is minimal documentation on this keyword (it does not
> > state that it can be used in declarations, even though it can), so I wonder
> > what the "rules" are.  
> 
> The documentation says
> 
>   '-pedantic' and other options cause warnings for many GNU C extensions.
>   You can prevent such warnings within one expression by writing
>   '__extension__' before the expression.  '__extension__' has no effect
>   aside from this.
> 
> It's not clear to me why you cannot simply put __extension__ earlier in
> your case?

If I am modifying tests on an individual basis, then indeed I can put
__extension__ earlier in the declaration and it fixes the issue.

But for a fix within the compiler to prevent having to modify individual tests,
I could add __extension__ to the beginning of the macro - but the macro may
not end up at the beginning of a declaration in the source code.

For example, say __SIZE_TYPE__ now expands to "__extension__ __int20 unsigned",
then the following usage of __SIZE_TYPE__ would be ok, as __extension__ is at
the beginning of the declaration:

> __SIZE_TYPE__ size;

But the following would emit an error, because __extension__ is not at the
beginning of the declaration:

> typedef __SIZE_TYPE__ size_t;

I'm mainly just wondering if a change to the compiler to allow the usage of
__extension__ within a declaration would be allowed.
However since there are many contexts where usage of a type such as
__SIZE_TYPE__ is valid, but where __extension__ preceding the type wouldn't be
valid, this is probably not worth exploring..

I'm aware of some different ways that the tests can be fixed up to prevent
the ISO C errors caused by -pedantic-errors.
I'm currently thinking the best way to fix these issues in the testsuite might
be to implement a directive such as "dg-prune-options". This directive can then
prune "-pedantic-errors" from the options to be passed to GCC when some
specified condition (e.g. -mlarge is in the opt list) is matched.
This would at least avoid having to re-jig tests to get the __extension__
keyword into the right places, as the dg-prune-options can just be added to the
problematic tests.

Thanks,
Jozef