On 6/17/26 5:18 PM, Marek Polacek wrote:
On Wed, Jun 17, 2026 at 12:34:27PM -0400, Jason Merrill wrote:
On 6/17/26 10:48 AM, Marek Polacek wrote:
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
Recently I had to parse this condition and it was a grievous experience.
I did not end up changing it in the end, but we still may want to
factor it out for the next reader.
gcc/cp/ChangeLog:
* decl.cc (do_full_aggr_init_p): New, factored out of...
(check_initializer): ...here. Use it.
---
gcc/cp/decl.cc | 45 +++++++++++++++++++++++++++++++++------------
1 file changed, 33 insertions(+), 12 deletions(-)
diff --git a/gcc/cp/decl.cc b/gcc/cp/decl.cc
index 23f23b39544..50a5684d1a3 100644
--- a/gcc/cp/decl.cc
+++ b/gcc/cp/decl.cc
@@ -8430,6 +8430,38 @@ build_aggr_init_full_exprs (tree decl, tree init, int
flags)
return build_aggr_init (decl, init, flags, tf_warning_or_error);
}
+/* Return true if we should call build_aggr_init_full_exprs in
+ check_initializer. INIT is the initializer for DECL. TYPE is
+ the type of DECL. */
+
+static bool
+do_full_aggr_init_p (tree decl, tree type, tree init, int flags)
+{
+ /* Always use build_aggr_init for array decomposition. */
+ if (DECL_DECOMPOSITION_P (decl) && TREE_CODE (type) == ARRAY_TYPE)
+ return true;
+
+ if (flags & LOOKUP_ALREADY_DIGESTED)
+ return false;
+
+ if (!(type_build_ctor_call (type) || CLASS_TYPE_P (type)))
+ return false;
+
So the below is deciding when we want to do aggregate initialization rather
than constructor/build_vec_init, even though we just established that there
are constructors in play.
+ if (init
+ && BRACE_ENCLOSED_INITIALIZER_P (init)
+ && CP_AGGREGATE_TYPE_P (type)
I wonder what happens if we drop the conditions below and just always return
false for {} of an aggregate? The below is trying to carve out a very thin
slice of types, and I doubt that's still useful as we have added more and
more exceptions. In particular, the gap between the type_build_ctor_call
above and the TYPE_NEEDS_CONSTRUCTING below is small enough to seem
insignificant.
Though also, maybe dropping the below conditions reduces the motivation to
factor this out into a separate function?
Removing the nested (a || ...) passes all the testing and makes the
condition more readable so that works for me too.
Bootstrapped/regtested on ppc64le-pc-linux-gnu, ok for trunk?
OK.
-- >8 --
This condition has become unwieldy and hard to read.
In <https://gcc.gnu.org/pipermail/gcc-patches/2026-June/720712.html>
I tried to factor it out into a separate function but it works to
just drop the complicated inner disjunction. I ran the testsuite
checking if we exercise the case where the new and old conditions
evaluate to different values and many tests triggered that.
gcc/cp/ChangeLog:
* decl.cc (check_initializer): Don't call
build_aggr_init_full_exprs for {} of an aggregate.
---
gcc/cp/decl.cc | 12 +++---------
1 file changed, 3 insertions(+), 9 deletions(-)
diff --git a/gcc/cp/decl.cc b/gcc/cp/decl.cc
index 23f23b39544..50ebb38b55b 100644
--- a/gcc/cp/decl.cc
+++ b/gcc/cp/decl.cc
@@ -8587,15 +8587,9 @@ check_initializer (tree decl, tree init, int flags,
vec<tree, va_gc> **cleanups)
if (((type_build_ctor_call (type) || CLASS_TYPE_P (type))
&& !(flags & LOOKUP_ALREADY_DIGESTED)
- && !(init && BRACE_ENCLOSED_INITIALIZER_P (init)
- && CP_AGGREGATE_TYPE_P (type)
- && (CLASS_TYPE_P (type)
- /* The call to build_aggr_init below could end up
- calling build_vec_init, which may break when we
- are processing a template. */
- || processing_template_decl
- || !TYPE_NEEDS_CONSTRUCTING (type)
- || type_has_extended_temps (type))))
+ && !(init
+ && BRACE_ENCLOSED_INITIALIZER_P (init)
+ && CP_AGGREGATE_TYPE_P (type)))
|| (DECL_DECOMPOSITION_P (decl) && TREE_CODE (type) == ARRAY_TYPE))
{
init_code = build_aggr_init_full_exprs (decl, init, flags);
base-commit: d1c12591336de2358c7da4a45855ddac2e02edda
