https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99216
--- Comment #5 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> --- (In reply to Alex Coplan from comment #4) > Right, the problem appears to be to do with the way that overloaded > functions are implemented for the ACLE. Specifically the m_direct_overloads > flag in aarch64_sve::function_builder. If this flag is set, we register a > separate builtin (with a separate function code) for each overload as > opposed to registering the overloaded function once and resolving it later. > The two different schemes end up with each builtin having a different code. > > We set m_direct_overloads to be true if the language is C++: > > m_direct_overloads = lang_GNU_CXX (); > > so in cc1plus, we use one numbering scheme, but in lto1, we use a different > numbering scheme, with predictably disastrous consequences (we try and > expand svaddv as an svbic). > > So one options would be that for LTO we instantiate both sets of tree nodes. > Then, when expanding a tree node that came from LTO, we dispatch on a flag > in the tree node (essentially just whether it came from C++ or not) to > determine which set of functions to use. Seems a bit messy though. > > @Richard: does that sound at all sane? Any ideas for a better approach? I think we should just make the non-C++ codes line up with the C++ ones by pushing a dummy entry onto registered_functions (but not creating or registering a decl for it).
