[Bug libstdc++/113099] locale without RTTI uses dynamic_cast before gcc 13.2 or has ODR violation since gcc 13.2

["andysem at mail dot ru" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113099

--- Comment #13 from andysem at mail dot ru ---
(In reply to Jonathan Wakely from comment #12)
> (In reply to andysem from comment #11)
> > > I'm not sure what you mean by "the compiler is free to generate code that takes it into account." Takes what into account? What problem does that freedom cause?
> > 
> > I mean the compiler could move (some part of) dynamic_cast to precede the
> > check for the standard facet. I.e. of something like this:
> > 
> >   template< typename _Facet >
> >   const _Facet* __try_use_facet(locale const& loc)
> >   {
> >     const size_t __i = _Facet::id._M_id();
> >     const locale::facet** __facets = __loc._M_impl->_M_facets;
> >     const _Facet* __dyn_facet = __dynamic_cast< const _Facet*
> > >(__facets[__i]);
> > 
> >     // checks for every standard facet type
> >     if (__is_same(_Facet, ...))
> >       return static_cast<const _Facet*>(__facets[__i]);
> > 
> >     return __dyn_facet;
> >   }
> 
> But why? Maybe I'm being slow but I still don't understand what problem is
> being solved here.
> 
> Also this would defeat the optimization that avoids the unnecessary overhead
> of dynamic_cast for standard facets.

I have seen gcc sometimes reorder code like this (i.e. move code from under a
branch before it), presumably to improve ILP or prefetch data, I'm not sure.
Yes, that defeats the branch, if it is used as an optimization, and I had to
prevent this by adding compiler fences in those cases. Granted, in my case it
happened with inlined code, but I imagine LTO makes it possible to perform
similar code transformations with out-of-line code as well.

I'm not saying this is what actually happens. I'm just pointing out that even
the code that is apparently unreachable may influence codegen and cause ODR
issues.

> > AFAIK, the standard or libstdc++ docs do not require RTTI for std::locale to
> > function.
> 
> The standard requires RTTI, period. Using -fno-rtti is completely
> non-standard and so the standard has nothing to say about it.

Yes, but the standard is written with implementations in mind.