On 10/2/26 1:50 PM, Dominic P wrote:
expand_constructor passed int_expr_size to store_constructor, which is
-1 for a type whose size is a POLY_INT_CST.  The RECORD_TYPE case then
skipped clear_storage, so an empty CONSTRUCTOR of an SVE or RVV tuple
type stored nothing: a register target got only a clobber and a memory
target was left unchanged.  Pass the poly size instead; only types with
a POLY_INT_CST size are affected.

Bootstrapped and regression tested on x86_64-pc-linux-gnu.  On
aarch64-linux-gnu (qemu), regression tested dg.exp, aarch64.exp and
the SVE tests at SVE VL128, and the SVE tests at VL2048.  On
riscv64, compiling gcc.target/riscv/rvv/base changes the asm of the new
test only.  Tested together with the previous patch and the PR123370
patch.

Assisted-by: Claude Opus 5 (Anthropic)

        PR middle-end/121105

gcc/ChangeLog:

        * expr.cc (expand_constructor): Pass a poly_int64 size to
        store_constructor.

gcc/testsuite/ChangeLog:

        * gcc.target/aarch64/sve/pr121105_1.c: New test.
        * gcc.target/aarch64/sve/pr121105_2.c: New test.
        * g++.target/aarch64/sve/pr121105.C: New test.
        * gcc.target/riscv/rvv/base/pr121105.c: New test.

Signed-off-by: Dominic P <[email protected]>
---
  gcc/expr.cc                                   |   5 +-
  .../g++.target/aarch64/sve/pr121105.C         |  13 ++
  .../gcc.target/aarch64/sve/pr121105_1.c       | 121 ++++++++++++++++++
  .../gcc.target/aarch64/sve/pr121105_2.c       |  33 +++++
  .../gcc.target/riscv/rvv/base/pr121105.c      |  21 +++
  5 files changed, 192 insertions(+), 1 deletion(-)
  create mode 100644 gcc/testsuite/g++.target/aarch64/sve/pr121105.C
  create mode 100644 gcc/testsuite/gcc.target/aarch64/sve/pr121105_1.c
  create mode 100644 gcc/testsuite/gcc.target/aarch64/sve/pr121105_2.c
  create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/pr121105.c

diff --git a/gcc/expr.cc b/gcc/expr.cc
index a9157dc5d41..6f8255f2d9f 100644
--- a/gcc/expr.cc
+++ b/gcc/expr.cc
@@ -9573,7 +9573,10 @@ expand_constructor (tree exp, rtx target, enum 
expand_modifier modifier,
        target = assign_temp (type, TREE_ADDRESSABLE (exp), 1);
      }
- store_constructor (exp, target, 0, int_expr_size (exp), false);
+  poly_int64 size;
+  if (!poly_int_tree_p (size_in_bytes (type), &size))
+    size = -1;
+  store_constructor (exp, target, 0, size, false);
    return target;
  }
I'd be tempted to assert a sensible size either before the call to store_constructor or in store_constructor itself for sanity's sake. I'd hate someone to have to dive back into another case of an uninitialized object sneaking through unexpectedly.

jeff

Reply via email to