This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c++/85569] [8/9 Regression] is_invocable(F, decltype(objs)...) fails with "not supported by dump_expr#" unless via indirection


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

--- Comment #8 from Alexandre Oliva <aoliva at gcc dot gnu.org> ---
Author: aoliva
Date: Wed Dec  5 06:47:11 2018
New Revision: 266816

URL: https://gcc.gnu.org/viewcvs?rev=266816&root=gcc&view=rev
Log:
[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.

Added:
    trunk/gcc/testsuite/g++.dg/cpp1z/pr85569.C
Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/constexpr.c
    trunk/gcc/testsuite/ChangeLog

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]