[PATCH] have -Wnonnull print inlining stack (PR 83369)

[Jeff Law]

On 12/11/2017 03:18 PM, Martin Sebor wrote:
> On 12/11/2017 02:08 PM, David Malcolm wrote:
>> On Mon, 2017-12-11 at 09:51 -0700, Martin Sebor wrote:
>>> Bug 83369 - Missing diagnostics during inlining, notes that when
>>> -Wnonnull is issued for an inlined call to a built-in function,
>>> GCC doesn't print the inlining stack, making it hard to debug
>>> where the problem comes from.
>>>
>>> When the -Wnonnull warning was introduced into the middle-end
>>> the diagnostic machinery provided no way to print the inlining
>>> stack (analogous to %K for trees).  Since then GCC has gained
>>> support for the %G directive which does just that.  The attached
>>> patch makes use of the directive to print the inlining context
>>> for -Wnonnull.
>>>
>>> The patch doesn't include a test because the DejaGnu framework
>>> provides no mechanism to validate this part of GCC output (see
>>> also bug 83336).
>>>
>>> Tested on x86_64-linux with no regressions.
>>>
>>> Martin
>>
>> I'm wondering if we should eliminate %K and %G altogether, and make
>> tree-diagnostic.c and friends automatically print the inlining stack
>> -they just need a location_t (the issue is with system headers, I
>> suppose, but maybe we can just make that smarter: perhaps only suppress
>> if every location in the chain is in a system header?).  I wonder if
>> that would be GCC 9 material at this point though?
> 
> Getting rid of %G and %K sounds fine to me.  I can't think of
> a use case for suppressing middle end diagnostics in system
> headers so unless someone else can it might be a non-issue.
> Since the change would fix a known bug it seems to me that it
> should be acceptable even at this stage.
My recollection is we suppress warnings from bits in system headers
because neither we nor the end users necessarily have control over the
contents of the system headers -- in which case we'd be issuing warnings
for something that only the vendor can fix.


I believe default suppression of warnings from system headers probably
needs to stay.
jeff