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
