This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]