[Bug c++/103600] Cannot use typeid result in constant expressions

["jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hubicka at gcc dot gnu.org,
                   |                            |jakub at gcc dot gnu.org,
                   |                            |jason at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
We handle e.g.
constexpr auto x = &typeid(int) == &typeid(int);
or
int a, b;
constexpr auto y = &a == &b;
The former by the (cmp @0 @0) folding in match.pd, the latter by
the address_compare match.pd patterns.
But, we already punt on e.g.
template <int N>
inline int a = N;
constexpr auto c = &a<0> == &a<1>;
because address_compare -> equal_address_to punts on those,
decl_binds_to_current_def_p is false (they are comdat and can end up being
defined from some other TU etc.).
And similarly it punts in the
&typeid(int) == &typeid(long)
case, neither _ZTIi nor _ZTIl are defined in the current TU (both are defined
in libstdc++) and the code attempts to play safe, say if the actual definitions
would be aliases of each other etc.

I guess at least for constexpr evaluation we want to have some C++ rules, both
for typeid vars - dunno if we can rely on the get_tinfo_decl_direct created
vars to be always different if they aren't the same VAR_DECL, or if we need to
e.g. compute the name and compare those, or for stuff like inline vars or
variable templates.  And the question is if cxx_eval_binary_expression should
for EQ_EXPR/NE_EXPR repeat what the match.pd address_compare simplification
does with its own address_compare, or if it should temporarily set some
langhook and
let address_compare use that langhook to handle the special cases, or if a
langhook should handle some of those cases always for C++.

Another case is the typeid(int) == typeid(long) comparison, operator== is I
think
    bool operator==(const type_info& __arg) const _GLIBCXX_NOEXCEPT
    {
      return ((__name == __arg.__name)                        
              || (__name[0] != '*' &&                         
                  __builtin_strcmp (__name, __arg.__name) == 0));
    }
so we'd need to be able to constant fold during constexpr evaluation
typeid(int).__name to &_ZTSi when the typeinfo isn't defined locally and
handle &_ZTSwhatever similarly to &_ZTIwhatever, but further we even need to
constant fold reading from those strings even when they aren't local..