On 6/25/25 12:49 PM, Jakub Jelinek wrote:
On Wed, Jun 25, 2025 at 12:37:33PM -0400, Jason Merrill wrote:
Ah, looks like fixed_type_or_null needs to handle a CALL_EXPR of class type
like a TARGET_EXPR. I also wonder why the call isn't already wrapped in a
TARGET_EXPR by build_cxx_call=>build_cplus_new at this point.
Wonder if it has anything to do with being in unevaluated context
It seems to be bugginess in the handling of decltype_p, which is
supposed to only apply to the immediate operand of decltype; the
attached fixes the testcase. I think we also still want the change to
fixed_type_or_null.
(and
whether perhaps cp_build_addr_expr isn't undesirable for that case, because
that can make vars odr-used etc.; are are odr uses in unevaluated context
also supposed to make vars odr-used?).
That's fine, mark_used handles not actually odr-using things in
unevaluated context.From 2cf9705f22ce2edcf749ef6721b1ee6c12dddd00 Mon Sep 17 00:00:00 2001
From: Jason Merrill <ja...@redhat.com>
Date: Wed, 25 Jun 2025 16:26:56 -0400
Subject: [PATCH] c++: fix decltype_p
To: gcc-patches@gcc.gnu.org
gcc/cp/ChangeLog:
* parser.cc (cp_parser_binary_expression): Don't pass decltype_p
to the operands.
---
gcc/cp/parser.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
index 80fd7990bbb..ba12c50fa7b 100644
--- a/gcc/cp/parser.cc
+++ b/gcc/cp/parser.cc
@@ -10791,7 +10791,7 @@ cp_parser_binary_expression (cp_parser* parser, bool cast_p,
current.lhs_type = (cp_lexer_next_token_is (parser->lexer, CPP_NOT)
? TRUTH_NOT_EXPR : ERROR_MARK);
current.lhs = cp_parser_cast_expression (parser, /*address_p=*/false,
- cast_p, decltype_p, pidk);
+ cast_p, /*decltype_p*/false, pidk);
current.prec = prec;
if (cp_parser_error_occurred (parser))
--
2.49.0
