This is the mail archive of the
mailing list for the GCC project.
Ping: [RFC, PATCH] Display inlining context for uninitialized warnings
- From: Vladislav Ivanishin <vlad at ispras dot ru>
- To: Jeff Law <law at redhat dot com>
- Cc: Martin Sebor <msebor at gmail dot com>, gcc-patches at gcc dot gnu dot org, David Malcolm <dmalcolm at redhat dot com>
- Date: Wed, 24 Jul 2019 15:37:35 +0300
- Subject: Ping: [RFC, PATCH] Display inlining context for uninitialized warnings
- References: <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org>
I'm pinging <https://gcc.gnu.org/ml/gcc-patches/2019-06/msg01124.html>.
I think, there are two subtopics to it that can be discussed separately.
I would like to focus on the patch itself here. I am going to also
start a subthread dedicated to dealing with representative returns.
I still have the same questions I had when I was sending the patch.
I am going to reiterate them, but in a more structured/focused fashion.
> When percent_K_format is called, TEXT might already hold precise
> location information in case its (indirect) caller is
> warning_at/error_at. So it seems to me, this function lacks
> distinguishing the two cases: being called from plain warning/error
> functions vs. their *_at counterparts (the location shouldn't be
> updated in the latter case).
David, do you agree? Should a discriminator of some sort be introduced?
> Sometimes inlining context is still lost (with the current patch), as
> can be seen e.g. with a version of the test with 's/unsigned yo/int yo/'
> substitution applied. (The chain of block = BLOCK_SUPERCONTEXT (block)
> is broken - it ends with 0 rather than a FUNCTION_DECL.) Is this known
> and expected (e.g. because pass_late_warn_uninitialized runs very late),
> or something to be investigated and fixed?
I don't know whom to address this question to. I guess I'll just go
ahead and investigate if no expert shows up.
> The patch was bootstrapped and regtested on x86_64-pc-linux-gnu.
> Shall it be applied?
Addressing the two points above would make the solution more complete.
However, I think, the patch is still beneficial as-is, and it is not
hacky. Re-tested, no regressions.