On Wed, 22 Jun 2016, David Malcolm wrote:
> PR c/71613 identifies a problem where we fail to report this enum:
>
> enum { e1 = LLONG_MIN };
>
> with -pedantic, due to LLONG_MIN being inside a system header.
>
> This patch updates the C and C++ frontends to use the location of the
> name as the primary location in the diagnostic, supplying the location
> of the value as a secondary location, fixing the issue.
>
> Before:
> $ gcc -c /tmp/test.c -Wpedantic
> /tmp/test.c: In function 'main':
> /tmp/test.c:3:14: warning: ISO C restricts enumerator values to range of
> 'int' [-Wpedantic]
> enum { c = -3000000000 };
> ^
>
> After:
> $ ./xgcc -B. -c /tmp/test.c -Wpedantic
> /tmp/test.c: In function 'main':
> /tmp/test.c:3:10: warning: ISO C restricts enumerator values to range of
> 'int' [-Wpedantic]
> enum { c = -3000000000 };
> ^ ~~~~~~~~~~~
>
> Successfully bootstrapped®retested on x86_64-pc-linux-gnu;
> adds 13 PASS results to gcc.sum and 9 PASS results to g++.sum.
>
> OK for trunk?
The C front-end changes are OK for the diagnostic improvement, although I
think piecemeal fixes make no sense for the issue of missing diagnostics -
in the absence of a clear strategy to identify which cases should or
should get diagnostics when a macro from a system header is expanded
outside a system header, we need to make the default to give the
diagnostics if the expansion location is outside a system header. (This
applies both to the general diagnostic disabling outside system headers,
and to specific tests for being in system headers in front ends - those
specific tests may or may not be relics left over from before the general
disabling was added.)
--
Joseph S. Myers
[email protected]
