This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] PR91195: fix -Wmaybe-uninitialized warning for conditional store optimization
- From: Jeff Law <law at redhat dot com>
- To: Martin Sebor <msebor at gmail dot com>, Richard Biener <richard dot guenther at gmail dot com>, Jakub Jelinek <jakub at redhat dot com>
- Cc: JiangNing OS <jiangning at os dot amperecomputing dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 7 Aug 2019 16:03:54 -0600
- Subject: Re: [PATCH] PR91195: fix -Wmaybe-uninitialized warning for conditional store optimization
- References: <MN2PR01MB5424AEF5B753FFAEB6FEB00E9CC70@MN2PR01MB5424.prod.exchangelabs.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <20190729160348.GD15878@tucnak> <CAFiYyc3sV7eXTRo9SCxXdv=FX-3iQ56N1_qzr-2VQLGCdR_f+Q@mail.gmail.com> <20190730083458.GN15878@tucnak> <CAFiYyc26jiy2Lcu33gzFv8VOv802vbbWjR8VxVBzhpFZ-eQvqA@mail.gmail.com> <email@example.com>
On 7/30/19 8:42 AM, Martin Sebor wrote:
> On 7/30/19 2:44 AM, Richard Biener wrote:
>> On Tue, Jul 30, 2019 at 10:35 AM Jakub Jelinek <firstname.lastname@example.org> wrote:
>>> On Tue, Jul 30, 2019 at 10:21:15AM +0200, Richard Biener wrote:
>>>> Would you need to LTO stream & merge the bitmaps / maps somehow?
>>> Yes. And if we do not throw unneeded warnings from the sets
>>> normally, LTO
>>> streaming might be a good time to do that, so that we merge in only
>>> that will be tested during/post IPA.
>>>> (maybe "unmap" to sth else when streaming individual stmts) Not
>>>> sure if
>>>> a bitmap is really necessary, we could simply have a tree/gimple *
>>>> -> vec<>
>>>> mapping with records about emitted (or queued) diagnostics, like
>>>> OPT_, message pairs or so.
>>> Right now we use it both for the case we've already emitted some
>>> and don't want to emit it again later, or for the case where we insert
>>> something in the IL that a warning could be diagnosed on but we know we
>>> don't want that. The latter is the case e.g. for when we add
>>> TREE_NO_WARNING on the last value in a statement expression so that
>>> we don't
>>> diagnose it as unused, or the case we are discussing here.
>>> If we need queued diagnostics, sure, we could add it in, but I don't
>>> see a
>>> need for that right now. vecs compared to bitmap might be larger and
>>> to avoid duplicates. I guess we'd need to do some analysis though,
>>> and e.g.
>>> if 99% of cases we need to disable just one warning and not multiple,
>>> perhaps optimize for that case.
>> I was thinking we may want to use the same facility to record warnings we
>> want to not emit if we later figure a stmt was in an unreachable
>> region. For
>> this we need to record the actual warning, not only the warning kind.
> I was thinking of introducing a __builtin_warning() for this and
> issuing it if it's not eliminated just before RTL expansion. That
> would let programs like libstdc++ use it too.
I've stated before, I think this is a *great* idea and would encourage
you to prototype it out to see if there's any significant gotchas.
There's several places I think we could use it.
> The downside of these solutions is that warnings may be issued out
> of order as code moves around. To have the issued in the order of
> increasing source lines they would need to be queued.
I think David is out right now, but I think he'd claim that emitting
diagnostics strictly in line number order isn't best anyway. Building a
queuing mechanism with an eye towards a more complex comparison to
facilitate priority ordering of diagnostics would be a good thing. He
may already have some prototype code, not sure on that.