Re: [PATCH] Fix source locations of bad enum values (PR c/71610 and PR c/71613)

[Joseph Myers <joseph at codesourcery dot com>]

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&regretested 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
joseph@codesourcery.com