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 <ja...@redhat.com> 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 >>> warnings >>> 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 >>> diagnostics >>> 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 >>> harder >>> 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. jeff
