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..
