On 12/11/2017 06:16 PM, David Malcolm wrote: > On Mon, 2017-12-11 at 15:18 -0700, 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. Is there any kind of consensus on what we want to do here -- do we want to try to tackle %G/%K removal for gcc-8 or defer it? If we defer it, how do we want to handle printing the inline stack in the interm?
jeff