aboutsummaryrefslogtreecommitdiff
path: root/gcc/cfgexpand.c
diff options
context:
space:
mode:
authorAlexandre Oliva <aoliva@redhat.com>2018-12-05 06:47:11 +0000
committerAlexandre Oliva <aoliva@gcc.gnu.org>2018-12-05 06:47:11 +0000
commit47be95094bc2d5c79320234a35e5049e0514fff1 (patch)
treea7af895bf2672ac18041041a977b2953ab63e6fc /gcc/cfgexpand.c
parent9d2e2d29baed70d965365c77aa3a8b8611f03cb9 (diff)
downloadgcc-47be95094bc2d5c79320234a35e5049e0514fff1.zip
gcc-47be95094bc2d5c79320234a35e5049e0514fff1.tar.gz
gcc-47be95094bc2d5c79320234a35e5049e0514fff1.tar.bz2
[PR85569] skip constexpr target_expr constructor dummy type conversion
The testcase is the work-around testcase for the PR; even that had started failing. The problem was that, when unqualifying the type of a TARGET_EXPR, we'd create a variant of the type, then request the conversion of the TARGET_EXPR_INITIAL to that variant type. Though the types are different pointer-wise, they're the same_type_p, so the resulting modified expr compares cp_tree_equal to the original, which maybe_constant_value flags as an error. There's no reason to construct an alternate TARGET_EXPR or CONSTRUCTOR just because of an equivalent type, except for another spot that expected pointer equality that would no longer be satisfied. Without relaxing the assert in constexpr_call_hasher::equal, g++.robertl/eb73.C would trigger an assertion failure. for gcc/cp/ChangeLog PR c++/85569 * constexpr.c (adjust_temp_type): Test for type equality with same_type_p. (constexpr_call_hasher::equal): Likewise. for gcc/testsuite/ChangeLog PR c++/85569 * g++.dg/cpp1z/pr85569.C: New. From-SVN: r266816
Diffstat (limited to 'gcc/cfgexpand.c')
0 files changed, 0 insertions, 0 deletions