On 3/17/26 9:57 AM, Marek Polacek wrote:
On Tue, Mar 17, 2026 at 10:12:03AM +0100, Jakub Jelinek wrote:
Hi!
On arm*-linux-gnueabi init11.C emits extra diagnostics which the testcase
doesn't expect.
E.g. it emits
init11.C: At global scope:
init11.C:19:13: error: function of consteval-only type must be declared
‘consteval’
19 | constexpr C() : i{} {} // { dg-error "function of consteval-only type
must be declared .consteval." }
| ^
init11.C: In constructor ‘constexpr C::C()’:
init11.C:19:24: error: consteval-only expressions are only allowed in a
constant-evaluated context
19 | constexpr C() : i{} {} // { dg-error "function of consteval-only type
must be declared .consteval." }
| ^
while on most other targets only the first error from these and not
the second is emitted.
This is because of targetm.cxx.cdtor_returns_this (), the error is emitted
on the constructor declaration and then again during
check_out_of_consteval_use on its body, when walking RETURN_EXPR (which
normally isn't there).
The following patch arranges diagnostics parity.
Bootstrapped/regtested on x86_64-linux and i686-linux and tested on
the testcase in cross to armv7-linux-gnueabi, ok for trunk?
Ok by me.
Yes, OK.
Though, as I wrote in the PR, I wonder if it makes sense to report
any errors on bodies of functions for which we've already diagnosed
function of consteval-only type must be declared ‘consteval’.
Especially for methods of consteval-only types, any use of this keyword
will result in an extra error (sure, only the first occurrence in a
function). But even if a function has only some other consteval-only
argument and that argument is used somewhere in the body. Though, wonder
if it is worth trying to improve that now when we don't know if
consteval-only will not be removed completely or changed significantly.
Indeed. Have you seen Barry's
https://isocpp.org/files/papers/D4101R0.html
? I like that direction, but can't say how others will feel about it.
2026-03-17 Jakub Jelinek <[email protected]>
PR c++/124474
* reflect.cc (check_out_of_consteval_use_r): Don't walk subtrees
of RETURN_EXPR on cdtor_returns_this targets in cdtors.
--- gcc/cp/reflect.cc.jj 2026-03-13 09:13:00.716259526 +0100
+++ gcc/cp/reflect.cc 2026-03-16 18:05:43.805570930 +0100
@@ -8246,6 +8246,17 @@ check_out_of_consteval_use_r (tree *tp,
}
}
+ /* Don't diagnose RETURN_EXPRs in cdtors on cdtor_returns_this
+ target. Those don't exist on other targets. */
+ if (TREE_CODE (t) == RETURN_EXPR
+ && targetm.cxx.cdtor_returns_this ()
+ && (DECL_CONSTRUCTOR_P (current_function_decl)
+ || DECL_DESTRUCTOR_P (current_function_decl)))
+ {
+ *walk_subtrees = false;
+ return NULL_TREE;
+ }
+
/* Now check the type to see if we are dealing with a consteval-only
expression. */
if (!consteval_only_p (t))
Jakub
Marek
