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?
-- >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
--
2.54.0
