https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101292
--- Comment #12 from rguenther at suse dot de <rguenther at suse dot de> --- On Tue, 18 Jan 2022, dcb314 at hotmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101292 > > --- Comment #11 from David Binderman <dcb314 at hotmail dot com> --- > (In reply to Thomas Schwinge from comment #9) > > (In reply to CVS Commits from comment #7) > > > The warning control falls into the C++ trap of using a reference > > > to old hashtable contents for a put operation which can end up > > > re-allocating that before reading from the old freed referenced to > > > source. Fixed by introducing a temporary. > > > > What the heck... I'd so much looked into this code and even refactored it > > in context of my earlier commit > > r12-3498-g6c79057fae6bbb36c4a4fd61c5b7107a16b71b17 "Don't maintain a warning > > spec for 'UNKNOWN_LOCATION'/'BUILTINS_LOCATION' [PR101574]" -- but I had not > > noticed that pre-existing problem. Thanks, Richard! > > > > > > In the general case, this is probably too complex to get a reliable > > diagnostic for (say, GCC Analyzer)? > > I had a look for the reallocate in put but couldn't see it. It's m_table::expand () that will use data_alloc from the allocator which eventually ends up in xcalloc and ::free for the release. Everything is in templates so it should be visible to the analyzer.
