Preventing ISO C errors when using macros for builtin types

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

The MSP430 target in the large memory model uses the (non-ISO) __int20 type for
SIZE_TYPE and PTRDIFF_TYPE.
The preprocessor therefore expands a builtin such as __SIZE_TYPE__ to
"__int20 unsigned" in user code.
When compiling with the "-pedantic-errors" flag, the use of any of these
builtin macros results in an error of the form:

> tester.c:4:9: error: ISO C does not support '__int20' types [-Wpedantic]

The GCC documentation does instruct users *not* to use these types directly
(cpp.texi):
> You should not use these macros directly; instead, include the
> appropriate headers and use the typedefs.
When using the typedefs (e.g. size_t) in a program compiled with
-pedantic-errors, there is no ISO C error.

However, in the testsuite there is an ever-growing list of tests which use
the macros to avoid having to include any header files required for the
typedefs.
Since -pendantic-errors is often passed as a default flag in the testsuite,
there are many false failures when testing with -mlarge, caused by this ISO C
error.

I would like to try to find a way to address this issue within GCC itself, so
that constant updates to the testsuite are not required to filter these types
of failures out.

I tried one approach suggested here
https://gcc.gnu.org/ml/gcc-patches/2018-11/msg02219.html
which was to add "__extension__" to the definition of SIZE_TYPE/PTRDIFF_TYPE in
msp430.h, however it became clear that that will not work, since the following
is not valid:
> typedef __extension__ __int20 ptrdiff_t;

> error: expected identifier or '(' before '__extension__'

__extension__ must be placed at the beginning of the declaration.

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.

I would appreciate if anyone can help me decide if:
- It would be OK for the use of builtin macros such as __SIZE_TYPE__ to somehow
  not trigger the "pedantic errors", and what a valid approach might look like
  * would finding a way to sandwich __extension__ into the expansion of these
    macros be acceptable?
  or,
- These types of failures should be continued to be fixed in the tests
  themselves, for example by adding __extension__ before their usage.

Thanks,
Jozef