On Wed, 5 Jun 2019 17:12:25 -0500 Segher Boessenkool <seg...@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 <seg...@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
