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

[Jozef Lawrynowicz <jozefl.gcc@gmail.com>]

On Wed, 5 Jun 2019 17:12:25 -0500
Segher Boessenkool <segher@kernel.crashing.org> wrote:

> On Wed, Jun 05, 2019 at 08:49:39PM +0100, Jozef Lawrynowicz wrote:
> > On Wed, 5 Jun 2019 11:49:21 -0500
> > Segher Boessenkool <segher@kernel.crashing.org> wrote:  
> > > 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.  
> 
> Or you could fix it like this in your header file?

If you're referring to the main target board header file (i.e.
gcc/config/msp430/msp430.h), I cannot add __extension__ to the definition
of SIZE_TYPE. It just breaks the build in too many places where a specific
format for SIZE_TYPE is expected. Should I manage to coerce the build into
succeeding, there would be further issues from the grammar rules regarding where
__extension__ can be placed in expressions/declarations anyway.

> > 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;  
> 
> Don't use macros for types?  You could use something like
> 
>   __extension__ typedef unsigned __int20 __SIZE_TYPE__;

I am only really concerned about the usage of __SIZE_TYPE__ in the
GCC testsuite (since real users shouldn't be using these macros, and the
user-facing typedefs do not cause ISO C errors), and it is in those tests that
there is uninhibited use of __SIZE_TYPE__ directly as a type. Combined with
-pedantic-errors being a default flag we see an ever expanding list of
failures. 

So to make tracking testsuite failures easier, I was looking for a way to
prevent these false errors by modifying the compiler itself. Failing that, a
simple and quick modification I can make to the tests would be satisfactory -
such as the aforementioned potential new DejaGNU directive to prune the
-pedantic-errors option before running the test.

The above typedef you suggested has in fact been similar to how I've been going
about fixing these failures so far, however it occurred to me that there should
be a better and more efficient way of avoiding these failures. 

> > I'm mainly just wondering if a change to the compiler to allow the usage of
> > __extension__ within a declaration would be allowed.  
> 
> Well, how would that work?  We'd need to modify the grammar to allow
> __extension__ pretty much anywhere, and then change all compiler code
> to not pedwarn until it has parsed a full expression (or statement, or
> file, or however this will work).  Or make it not warn for things after
> the __extension__ only, or make it only *guaranteed* not to warn for
> things *after* the __extension__.
> 
> None of those options are very appetising, IMO.

Yes I do agree with you, the mechanism for fixing this in the compiler would
require significant work for this relatively niche use case.
 
Thanks,
Jozef