https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127741
--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I think we have this in several spots in constexpr.cc, that we can only handle
INTEGER_CSTs and not arbitrary other integral constant expressions (or when not
manifestly constant evaluated also some superset of that).
&a is a constant expression (but requires relocation), reinterpret cast of that
to integer is not but is allowed as an extension in order not to regress, but
then there are clear cases which just can't be constant evaluated, say 5 *
(uintptr_t) &a
can't be constant, etc.
Some spots have e.g.
if (TREE_CODE (cond) != INTEGER_CST)
{
/* If the condition doesn't reduce to an INTEGER_CST it isn't a usable
switch condition even if it's constant enough for other things
(c++/113545). */
gcc_checking_assert (ctx->quiet);
*non_constant_p = true;
return t;
}
some assert a constant expression is an INTEGER_CST or just use it as one, even
when it isn't 100% guaranteed.
