https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87897
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Slightly cleaned up testcase:
typedef struct A {} B;
A const a = B ();
The problem is that we have a TARGET_EXPR with B type and an empty CONSTRUCTOR
with B type, then cxx_eval_outermost_constant_expr is processing it,
5111 if (TREE_CODE (r) == CONSTRUCTOR && CLASS_TYPE_P (TREE_TYPE (r)))
5112 {
5113 r = adjust_temp_type (type, r);
5114 if (TREE_CODE (t) == TARGET_EXPR
5115 && TARGET_EXPR_INITIAL (t) == r)
5116 return t;
5117 else if (TREE_CODE (t) != CONSTRUCTOR)
5118 {
5119 r = get_target_expr (r);
5120 TREE_CONSTANT (r) = true;
5121 }
and then in the caller
5259 r = cxx_eval_outermost_constant_expr (t, true, true, false, decl);
5260 gcc_checking_assert (r == t
5261 || CONVERT_EXPR_P (t)
5262 || TREE_CODE (t) == VIEW_CONVERT_EXPR
5263 || (TREE_CONSTANT (t) && !TREE_CONSTANT (r))
5264 || !cp_tree_equal (r, t));
For A const a = A (); adjust_temp_type returns the passed r and thus r == t in
the caller, but for A const a = B (); adjust_temp_type creates a new
CONSTRUCTOR (with A type), also a new TARGET_EXPR because of that, but both are
cp_tree_equal, as it doesn't care about exact type as long as it has
same_type_p.
So, shall adjust_temp_type not bother if it is same_type_p, or shall the assert
be adjusted, or shall we adjust the type earlier already? The assert is there
already since r166166.
