On Wed, Jun 5, 2019 at 3:26 PM Jozef Lawrynowicz <jozefl....@gmail.com> wrote: > > 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
I think that would be OK - note you could also modify your target board. Maybe we can trick libcpp to set in_system_header for those internal predefined macros so we do not warn on their expansions. We can also lookup macro expansion context and eventually see it is an internal macro. people more familiar with libcpp could say which approach is more reasonable. Richard. > * 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
