https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124478
Nathaniel Shead <nshead at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |nshead at gcc dot gnu.org
Last reconfirmed| |2026-03-13
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #2 from Nathaniel Shead <nshead at gcc dot gnu.org> ---
Confirmed. This is an interesting one... the issue is that when lazily loading
'analyse_text', we load the declaration of DedupeFilesPath from 'tools', where
we have CLASSTYPE_LAZY_DESTRUCTOR set, and no destructor yet available.
We then need to synthesize the destructor for the return of the call, and so
call 'lazily_declare_fn', which sets CLASSTYPE_LAZY_DESTRUCTOR to 0 and calls
'implicitly_declare_fn', which starts synthesizing the destructor for each
member. For the 'std::vector<std::string>', this calls 'lazy_load_pendings'
which starts loading all declarations bound to the key 'vector' (i.e. all
declarations attached to vectors that aren't found by name).
One of these declarations it finds is the destructor for
std::vector<DedupeFilesPath> which was generated in dedupe::lsh. This in turn
requires the destructor of DedupeFilePath, which was implicitly declared in
this module, so we load that.
But then in 'install_implicit_member' we crash, because
CLASSTYPE_LAZY_DESTRUCTOR is now zero, despite us not having actually built the
destructor yet!
I'm not immediately sure how to untangle this. One approach that would fix
this specific case is to check after 'synthesize_method_walk' whether the
function has already been lazily loaded somehow, and only clear
CLASSTYPE_LAZY_* and proceed at that point. But I'm not sure if there might be
other, even more obscure paths to the same issue.
