On Mon, Jul 29, 2019 at 6:03 PM Jakub Jelinek <ja...@redhat.com> wrote: > > On Wed, Jul 24, 2019 at 12:07:36PM -0600, Martin Sebor wrote: > > > > There are a number of existing instances of setting TREE_NO_WARNING > > > > to suppress -Wuninitialized, and some are the cause of known problems. > > > > Bugs 51545, 58950, 74762, 74765 or 89697 are examples. They all boil > > > > down to the fact that there's just one bit for all warnings. Jakub > > > > mentioned adding a hash-map for this. That seems like a simple and > > > > good solution. > > > I'm not sure how that really helps here. We marking the MEM on the LHS > > > and that's not a shared object. I don't see how it's going to be > > > significantly different using a hash map vs the bit in this circumstance. > > > > I don't know what Jakub had in mind but the mapping I envision is > > one like hash_map<tree, bitmap> that would make it possible to set > > a bit for each distinct warning for every tree node. It would let > > us set a bit for -Wuninitialized while leaving the bit for > > -Warray-bounds (and all other warnings) clear. > > I had in mind something like a hash_map<tree, const_bitmap> / hash_map<gimple > *, > const_bitmap> (or just make it a <void *, const_bitmap>) where possibly the > bitmaps would be shared, so have a hash table in which one would look up > existing > bitmaps containing particular sets of warnings and if not create a new one > (and > where the bitmaps would be const after creation). > The TREE_NO_WARNING or gimple_no_warning bits would be a flag that one > should look up the hash_map if needed, those bits clear would imply empty > bitmap. Routines that copy trees or gimple stmts, like copy_node or > gimple_copy would take care of adding the new tree/gimple * into the > hash_map if needed too. > And, because we have a lot of warnings that are only emitted in the FEs, or > say before IPA and not afterwards, we could also have spots where we'd > replace the bitmaps with ones that don't have any of the no longer > interesting warning bits. > Say during gimplification we could drop TREE_NO_WARNING bit or not set > gimple_no_warning if the bitmap only contains FE warning bits, or (perhaps > more questionable whether worth it) replace with a const_bitmap that doesn't > have those).
Would you need to LTO stream & merge the bitmaps / maps somehow? (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. Richard. > > Jakub
