This testcase was made latent by r14-4089 and got fixed both
on the trunk and 13 branch with PR113372 fix.
Adding testcase to the testsuite and will close the PR as a dup.
2024-03-28 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/109925
* gcc.c-torture/execute/pr109925.c: New test.
The patch fixing PR111781 made the check of specification expressions more
restrictive, disallowing local variables in specification expressions of
dummy arguments. PR114475 showed an example where that change regressed,
disallowing in submodules expressions that had been allowed in the parent
module. In submodules indeed, the hierarchy of namespaces inherited from
the parent module is not reproduced so the host-association of symbols
can't be recognized by checking the nesting of namespaces.
This change fixes the problem by allowing in specification expressions
all the symbols in a submodule that are inherited from the parent module.
PR fortran/111781
PR fortran/114475
gcc/fortran/ChangeLog:
* expr.cc (check_restricted): In submodules, allow variables host-
associated from the parent module.
gcc/testsuite/ChangeLog:
* gfortran.dg/spec_expr_10.f90: New test.
Co-authored-by: Harald Anlauf <anlauf@gmx.de>
This patch rebuilds the documentation for the target independent
library sections.
gcc/m2/ChangeLog:
* target-independent/m2/Builtins.texi: Rebuilt.
* target-independent/m2/gm2-libs.texi: Rebuilt.
Signed-off-by: Gaius Mulley <gaiusmod2@gmail.com>
The testcase in this PR shows very slow IDF compute:
tree SSA rewrite : 76.99 ( 31%)
24.78% 243663 cc1plus cc1plus [.] compute_idf
which can be mitigated to some extent by refactoring the bitmap
operations to simpler variants. With the patch below this becomes
tree SSA rewrite : 15.23 ( 8%)
when not optimizing and in addition to that
tree SSA incremental : 181.52 ( 30%)
to
tree SSA incremental : 24.09 ( 6%)
when optimizing.
PR middle-end/114480
* cfganal.cc (compute_idf): Use simpler bitmap iteration,
touch work_set only when phi_insertion_points changed.
We aren't doing anything with vxsat right now, but I'd like to add it as
an accepted register to the clobber list. If we get this into GCC-14
then we'll avoid some preprocessor-based twiddling if we ever start
using vxsat in the future.
gcc/ChangeLog:
* config/riscv/riscv.h (REGISTER_NAMES): Add vxsat.
gcc/analyzer/ChangeLog:
PR analyzer/114473
* call-summary.cc
(call_summary_replay::convert_svalue_from_summary): Assert that
the types match.
(call_summary_replay::convert_region_from_summary): Likewise.
(call_summary_replay::convert_region_from_summary_1): Add missing
cast for the deref of RK_SYMBOLIC case.
gcc/testsuite/ChangeLog:
PR analyzer/114473
* gcc.dg/analyzer/call-summaries-pr114473.c: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
> -/* The offset entry for each variable in a DATSEC should be 0 at compile time. */
> -/* { dg-final { scan-assembler-times "0\[\t \]+\[^\n\]*bts_offset" 7 } } */
> +/* The offset entry for each variable in a DATSEC should contain a label. */
> +/* { dg-final { scan-assembler-times ".4byte\[\t \]\[a-e\]\[\t \]+\[^\n\]*bts_offset" 5 } } */
4byte is used only on some targets, what exact assembler directive is used
for 4byte unaligned data is heavily target dependent.
2024-03-27 Jakub Jelinek <jakub@redhat.com>
* gcc.dg/debug/btf/btf-cvr-quals-1.c: Use dg-additional-options
instead of multiple dg-options.
* gcc.dg/debug/btf/btf-datasec-1.c: Likewise. Accept all supported
unaligned 4 byte assembler directives rather than assuming it must
be .4byte.
As written in the PR, torture/bitint-64.c test fails with -O2 -flto
and the reason is that on _BitInt arches where the padding bits
are undefined, the padding bits in the _Atomic vars are also undefined,
but when __atomic_load or __atomic_exchange on a _BitInt _Atomic variable
with some padding bits is lowered into __atomic_load_{1,2,4,8,16} or
__atomic_exchange_*, the mode precision unsigned result is VIEW_CONVERT_EXPR
converted to _BitInt and because of the VCE nothing actually sign/zero
extends it as needed for later uses - the var is no longer addressable and
expansion assumes such automatic vars are properly extended.
The following patch fixes that by using NOP_EXPR on it (the
VIEW_CONVERT_EXPR after it will then be optimized away during
gimplification, didn't want to repeat it in the code as else result = build1
(VIEW_CONVERT_EXPR, ...); twice.
2024-03-27 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/114469
* c-common.cc (resolve_overloaded_builtin): For _BitInt result
on !extended targets convert result to the _BitInt type before
using VIEW_CONVERT_EXPR.
In some cases combine will "combine" an I2 and I3, but end up putting
exactly the same thing back as I2 as was there before. This is never
progress, so we shouldn't do it, it will lead to oscillating behaviour
and the like.
If we want to canonicalise things, that's fine, but this is not the
way to do it.
2024-03-27 Segher Boessenkool <segher@kernel.crashing.org>
PR rtl-optimization/101523
* combine.cc (try_combine): Don't do a 2-insn combination if
it does not in fact change I2.
We got internally a question about the Spec File syntax, misunderstanding
what is the literal syntax and what are the placeholder variables in
the syntax descriptions.
The following patch attempts to use @var{S} etc. instead of just S
to clarify it stands for any option (or start of option etc.) rather
than literal S, say in %{S:X}. At least in HTML documentation it
then uses italics.
2024-03-27 Jakub Jelinek <jakub@redhat.com>
* doc/invoke.texi (Spec Files): Use @var{S} instead of S,
@var{X} instead of X etc. for other placeholders.
This resolves further failures (-Wreturn-type warnings) and test
failures for where-* tests targeting AVX-512.
Signed-off-by: Matthias Kretz <m.kretz@gsi.de>
libstdc++-v3/ChangeLog:
* include/experimental/bits/simd_x86.h (_S_masked_unary):
Cast inputs < 16 bytes to 16 byte vectors before calling the
right subtraction builtin. Before returning, truncate to the
return vector type.
This resolves failures in the "expensive" where-* test of check-simd
when targeting AVX-512.
Signed-off-by: Matthias Kretz <m.kretz@gsi.de>
libstdc++-v3/ChangeLog:
* include/experimental/bits/simd_x86.h (_S_masked_unary): Call
the 4- and 8-byte variants of __builtin_ia32_subp[ds] without
rounding direction argument.
libstdc++-v3/ChangeLog:
* include/Makefile.am: Add simd_sve.h.
* include/Makefile.in: Add simd_sve.h.
* include/experimental/bits/simd.h: Add new SveAbi.
* include/experimental/bits/simd_builtin.h: Use
__no_sve_deduce_t to support existing Neon Abi.
* include/experimental/bits/simd_converter.h: Convert
sequentially when sve is available.
* include/experimental/bits/simd_detail.h: Define sve
specific macro.
* include/experimental/bits/simd_math.h: Fallback frexp
to execute sequntially when sve is available, to handle
fixed_size_simd return type that always uses sve.
* include/experimental/simd: Include bits/simd_sve.h.
* testsuite/experimental/simd/tests/bits/main.h: Enable
testing for sve128, sve256, sve512.
* include/experimental/bits/simd_sve.h: New file.
Signed-off-by: Srinivas Yadav Singanaboina <vasu.srinivasvasu.14@gmail.com>
The following makes sure to record the scalars we add to the BB
reduction vectorization result as scalar uses for the purpose of
computing live lanes. This restores vectorization in the
bondfree.c TU of 435.gromacs.
PR tree-optimization/114057
* tree-vect-slp.cc (vect_bb_slp_mark_live_stmts): Mark
BB reduction remain defs as scalar uses.
These tests FAIL for quite a while on i686-linux since July last year,
likely r14-2628 . Since that patch gcc claims _Float16 and __bf16
support even without -msse2 because some functions could be using
target attribute.
Later r14-2691 added -msse2 to add_options_for_float16, but didn't do that
for bfloat16, plus ext-floating{3,12}.C tests need the added dg-add-options,
so that float16 and bfloat16 effective targets match the __STDCPP_FLOAT16_T__
or __STDCPP_BFLOAT16_T__ macros.
Fixes
-FAIL: g++.dg/cpp23/ext-floating12.C -std=gnu++23 (test for errors, line 144)
-FAIL: g++.dg/cpp23/ext-floating12.C -std=gnu++23 (test for errors, line 146)
-FAIL: g++.dg/cpp23/ext-floating12.C -std=gnu++23 (test for errors, line 148)
-FAIL: g++.dg/cpp23/ext-floating12.C -std=gnu++23 (test for errors, line 150)
-FAIL: g++.dg/cpp23/ext-floating12.C -std=gnu++23 (test for errors, line 152)
-FAIL: g++.dg/cpp23/ext-floating12.C -std=gnu++23 (test for errors, line 154)
-FAIL: g++.dg/cpp23/ext-floating12.C -std=gnu++26 (test for errors, line 144)
-FAIL: g++.dg/cpp23/ext-floating12.C -std=gnu++26 (test for errors, line 146)
-FAIL: g++.dg/cpp23/ext-floating12.C -std=gnu++26 (test for errors, line 148)
-FAIL: g++.dg/cpp23/ext-floating12.C -std=gnu++26 (test for errors, line 150)
-FAIL: g++.dg/cpp23/ext-floating12.C -std=gnu++26 (test for errors, line 152)
-FAIL: g++.dg/cpp23/ext-floating12.C -std=gnu++26 (test for errors, line 154)
-FAIL: g++.dg/cpp23/ext-floating3.C -std=gnu++23 (test for errors, line 107)
-FAIL: g++.dg/cpp23/ext-floating3.C -std=gnu++23 (test for errors, line 114)
-FAIL: g++.dg/cpp23/ext-floating3.C -std=gnu++23 (test for errors, line 126)
-FAIL: g++.dg/cpp23/ext-floating3.C -std=gnu++23 (test for errors, line 79)
-FAIL: g++.dg/cpp23/ext-floating3.C -std=gnu++23 (test for errors, line 86)
-FAIL: g++.dg/cpp23/ext-floating3.C -std=gnu++23 (test for errors, line 98)
-FAIL: g++.dg/cpp23/ext-floating3.C -std=gnu++23 (test for warnings, line 22)
-FAIL: g++.dg/cpp23/ext-floating3.C -std=gnu++23 (test for warnings, line 23)
-FAIL: g++.dg/cpp23/ext-floating3.C -std=gnu++23 (test for warnings, line 24)
-FAIL: g++.dg/cpp23/ext-floating3.C -std=gnu++23 (test for warnings, line 25)
-FAIL: g++.dg/cpp23/ext-floating3.C -std=gnu++26 (test for errors, line 107)
-FAIL: g++.dg/cpp23/ext-floating3.C -std=gnu++26 (test for errors, line 114)
-FAIL: g++.dg/cpp23/ext-floating3.C -std=gnu++26 (test for errors, line 126)
-FAIL: g++.dg/cpp23/ext-floating3.C -std=gnu++26 (test for errors, line 79)
-FAIL: g++.dg/cpp23/ext-floating3.C -std=gnu++26 (test for errors, line 86)
-FAIL: g++.dg/cpp23/ext-floating3.C -std=gnu++26 (test for errors, line 98)
-FAIL: g++.dg/cpp23/ext-floating3.C -std=gnu++26 (test for warnings, line 22)
-FAIL: g++.dg/cpp23/ext-floating3.C -std=gnu++26 (test for warnings, line 23)
-FAIL: g++.dg/cpp23/ext-floating3.C -std=gnu++26 (test for warnings, line 24)
-FAIL: g++.dg/cpp23/ext-floating3.C -std=gnu++26 (test for warnings, line 25)
on the latter and changes nothing on the former.
2024-03-27 Jakub Jelinek <jakub@redhat.com>
* lib/target-supports.exp (add_options_for_bfloat16): Add -msse2 on
i?86/x86_64.
* g++.dg/cpp23/ext-floating3.C: Add dg-add-options float16.
* g++.dg/cpp23/ext-floating12.C: Add dg-add-options float16 and
bfloat16.
Due to the Linux kernel exposing the lrcpc3 architectural feature as
"lrcpc3", this patch corrects the relevant FEATURE_STRING entry in the
"rcpc3" AARCH64_OPT_FMV_EXTENSION macro, such that the feature can be
correctly detected when doing native compilation on rcpc3-enabled
targets.
gcc/ChangeLog:
* config/aarch64/aarch64-option-extensions.def (rcpc3):
Fix FEATURE_STRING field to "lrcpc3".
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/cpunative/info_24: New.
* gcc.target/aarch64/cpunative/native_cpu_24.c: Likewise.
Given how, at present, the choice of using LSE128 atomic instructions
by the toolchain is delegated to run-time selection in the form of
Libatomic ifuncs, responsible for querying target support, the
`+lse128' target architecture compile-time flag is absent from GCC.
This, however, contrasts with the Binutils implementation, which gates
LSE128 instructions behind the `+lse128' flag. This can lead to
problems in GCC for certain use-cases. One such example is in the use
of inline assembly, whereby the inability of enabling the feature in
the command-line prevents the compiler from automatically issuing the
necessary LSE128 `.arch' directive.
This patch therefore brings GCC into alignment with LLVM and Binutils
in adding support for the `+lse128' architectural extension flag.
gcc/ChangeLog:
* config/aarch64/aarch64-option-extensions.def: Add LSE128
AARCH64_OPT_EXTENSION, adding it as a dependency for the D128
feature.
* doc/invoke.texi (AArch64 Options): Document +lse128.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/lse128-flag.c: New.
* gcc.target/aarch64/cpunative/info_23: Likewise.
* gcc.target/aarch64/cpunative/native_cpu_23.c: Likewise.
For targets where LOGICAL_OP_NON_SHORT_CIRCUIT evaluates to false, two
conditional jumps are emitted instead of a combined conditional which
this test is all about. Thus, set it to true.
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/copy-headers-8.c: Set
LOGICAL_OP_NON_SHORT_CIRCUIT to true.
Per the standard, the return type of a generators ranges iterator op*
should be the reference type rather than the yielded type.
The yielded type was used here by mistake.
libstdc++-v3/ChangeLog:
* include/std/generator (generator::_Iterator::operator*): Fix
return type.
* testsuite/24_iterators/range_generators/iter_deref_return.cc:
New test.
GCC 4.8 complained about the use of const rather than constexpr
for out-of-line static constexprs.
gcc/
* config/aarch64/aarch64-feature-deps.h: Use constexpr for
out-of-line statics.
GCC was defining bts_offset entry to always contain 0.
When comparing with clang, the same entry is instead a label to the
respective variable or function. The assembler emits relocations for
those labels.
gcc/ChangeLog:
PR target/114431
* btfout.cc (get_name_for_datasec_entry): Add function.
(btf_asm_datasec_entry): Print label when possible.
gcc/testsuite/ChangeLog:
* gcc.dg/debug/btf/btf-datasec-1.c: Correct for new
implementation.
* gcc.dg/debug/btf/btf-datasec-2.c: Likewise
* gcc.dg/debug/btf/btf-pr106773.c: Likewise
Apparently I've somehow screwed up the adjustments of the originally tested
testcase, tweaked it so that in the second/third cases it actually see
a MAX_EXPR rather than COND_EXPR the MAX_EXPR has been optimized into,
and didn't update the expected value.
2024-03-26 Jakub Jelinek <jakub@redhat.com>
PR middle-end/111151
PR testsuite/114486
* gcc.c-torture/execute/pr111151.c (main): Fix up expected value for
f.
We used to hit the "Error reporting routines re-entered." ICE here but
it was fixed by Patrick's r14-3809.
PR c++/100557
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-pr100557.C: New test.
The SCHEDULER_IDENT for these two CPUs
was incorrectly set to cortexa55.
This can cause sub-optimal asm
to be generated.
gcc/ChangeLog:
PR target/114272
* config/aarch64/aarch64-cores.def (AARCH64_CORE):
Change SCHEDULER_IDENT from cortexa55 to cortexa53
for Cortex-A510 and Cortex-A520.
Rmove the dejagnu code for checking whether std::stacktrace is supported
and just use the new dg-require-cpp-feature-test directive to check for
__cpp_lib_stacktrace instead.
libstdc++-v3/ChangeLog:
* testsuite/19_diagnostics/stacktrace/current.cc: Check for
__cpp_lib_stacktrace instead of check for stacktrace ET.
* testsuite/19_diagnostics/stacktrace/entry.cc: Likewise.
* testsuite/19_diagnostics/stacktrace/hash.cc: Likewise.
* testsuite/19_diagnostics/stacktrace/output.cc: Likewise.
* testsuite/19_diagnostics/stacktrace/stacktrace.cc: Likewise.
* testsuite/19_diagnostics/stacktrace/synopsis.cc: Likewise.
* testsuite/19_diagnostics/stacktrace/version.cc: Likewise.
* testsuite/23_containers/vector/debug/assign4_backtrace_neg.cc:
Likewise.
* testsuite/lib/libstdc++.exp (check_effective_target_stacktrace):
Remove.
This adds a new dejagnu directive which can be used to make a test
depend on a feature test macro such as __cpp_lib_text_encoding. This is
mroe flexible than writing a new dg-require-xxx for each feature.
libstdc++-v3/ChangeLog:
* testsuite/lib/dg-options.exp (dg-require-cpp-feature-test):
New proc.
* testsuite/lib/libstdc++.exp (check_v3_target_cpp_feature_test):
New proc.
* testsuite/std/text_encoding/cons.cc: Use new directive to skip
the test if the __cpp_lib_text_encoding feature test macro is
not defined.
* testsuite/std/text_encoding/requirements.cc: Likewise.
I've missed
FAIL: gcc.dg/torture/pr113126.c -O0 (test for excess errors)
etc. regressions on i686-linux since January. The problem is obvious
Excess errors:
.../gcc/testsuite/gcc.dg/torture/pr113126.c:11:1: warning: MMX vector return without MMX enabled changes the ABI [-Wpsabi]
and I've added -Wno-psabi to dg-additional-options to fix that up.
2024-03-26 Jakub Jelinek <jakub@redhat.com>
* gcc.dg/torture/pr113126.c: Add -Wno-psabi as dg-additional-options.
As I've tried to explain in the comments, the extract_muldiv_1
MIN/MAX_EXPR optimization is wrong for code == MULT_EXPR.
If the multiplication is done in unsigned type or in signed
type with -fwrapv, it is fairly obvious that max (a, b) * c
in many cases isn't equivalent to max (a * c, b * c) (or min if c is
negative) due to overflows, but even for signed with undefined overflow,
the optimization could turn something without UB in it (where
say a * c invokes UB, but max (or min) picks the other operand where
b * c doesn't).
As for division/modulo, I think it is in most cases safe, except if
the problematic INT_MIN / -1 case could be triggered, but we can
just punt for MAX_EXPR because for MIN_EXPR if one operand is INT_MIN,
we'd pick that operand already. It is just for completeness, match.pd
already has an optimization which turns x / -1 into -x, so the division
by zero is mostly theoretical. That is also why in the testcase the
i case isn't actually miscompiled without the patch, while the c and f
cases are.
2024-03-26 Jakub Jelinek <jakub@redhat.com>
PR middle-end/111151
* fold-const.cc (extract_muldiv_1) <case MAX_EXPR>: Punt for
MULT_EXPR altogether, or for MAX_EXPR if c is -1.
* gcc.c-torture/execute/pr111151.c: New test.
Similar to the asan and ubsan changes, we shouldn't instrument non-generic
address space accesses with tsan, because we just have library functions
which take address of the objects as generic address space pointers, so they
can't handle anything else.
2024-03-26 Jakub Jelinek <jakub@redhat.com>
PR sanitizer/111736
* tsan.cc (instrument_expr): Punt on non-generic address space
accesses.
* gcc.dg/tsan/pr111736.c: New test.
The following fixes too lax verification of vector type compatibility
in vectorizable_operation. When we only have a single vector size then
comparing the number of elements is enough but with SLP we mix those
and thus for operations like BIT_AND_EXPR we need to verify compatible
element types as well. Allow sign changes for ABSU_EXPR though.
PR tree-optimization/114471
* tree-vect-stmts.cc (vectorizable_operation): Verify operand
types are compatible with the result type.
* gcc.dg/vect/pr114471.c: New testcase.
The following adds missing verification of vector type compatibility
to recurrence vectorization.
PR tree-optimization/114464
* tree-vect-loop.cc (vectorizable_recurr): Verify the latch
vector type is compatible with what we chose for the recurrence.
* g++.dg/vect/pr114464.cc: New testcase.
I've noticed a comment typo in x86-tune.def and cfgloopmanip.cc has the
same typo as well.
2024-03-26 Jakub Jelinek <jakub@redhat.com>
* cfgloopmanip.cc (update_loop_exit_probability_scale_dom_bbs):
Fix comment typo - multple -> multiple.
* config/i386/x86-tune.def (X86_TUNE_ACCUMULATE_OUTGOING_ARGS):
Likewise.
I've noticed that the c-c++-common/gomp/depobj-3.c test FAILs on i686-linux:
PASS: c-c++-common/gomp/depobj-3.c -std=c++17 at line 17 (test for warnings, line 15)
FAIL: c-c++-common/gomp/depobj-3.c -std=c++17 at line 39 (test for warnings, line 37)
PASS: c-c++-common/gomp/depobj-3.c -std=c++17 at line 43 (test for errors, line 41)
PASS: c-c++-common/gomp/depobj-3.c -std=c++17 (test for warnings, line 45)
FAIL: c-c++-common/gomp/depobj-3.c -std=c++17 (test for excess errors)
Excess errors:
/home/jakub/src/gcc/gcc/testsuite/c-c++-common/gomp/depobj-3.c:37:38: warning: the 'destroy' expression ''excess_precision_expr' not supported by dump_expr<expression error>' should
+be the same as the 'depobj' argument 'obj' [-Wopenmp]
The following patch replaces that 'excess_precision_expr' not supported by dump_expr<expression error>
with (float)(((long double)a) + (long double)5)
Still ugly and doesn't actually fix the FAIL (will deal with that
incrementally), but at least valid C/C++ and shows the excess precision
handling in action.
2024-03-26 Jakub Jelinek <jakub@redhat.com>
PR c++/112724
gcc/c-family/
* c-pretty-print.cc (pp_c_cast_expression,
c_pretty_printer::expression): Handle EXCESS_PRECISION_EXPR like
NOP_EXPR.
gcc/cp/
* error.cc (dump_expr): Handle EXCESS_PRECISION_EXPR like NOP_EXPR.
Arm32 predefines __ARM_FEATURE_UNALIGNED if -mno-unaligned-access,
and RISC-V predefines __riscv_misaligned_avoid.
Let's define __mips_strict_alignment for MIPSr6 and -mstrict-align
is used.
Note that, this macro is always defined for pre-R6.
gcc
* config/mips/mips.h (TARGET_CPU_CPP_BUILTINS): Predefine
__mips_strict_alignment if STRICT_ALIGNMENT.
Patrick noticed that my r14-9339-gdc6c3bfb59baab patch is wrong;
we're dealing with a noexcept-spec there, not a noexcept-expr, so
setting cp_noexcept_operand et al is incorrect. Back to the drawing
board then.
To fix noexcept84.C, we should probably avoid doing push_to_top_level
in certain cases. maybe_push_to_top_level didn't work here as-is, so
I changed it to not push to top level if decl_function_context is
non-null, when we are not dealing with a lambda.
This also fixes c++/114349, introduced by r14-9339.
PR c++/114349
gcc/cp/ChangeLog:
* name-lookup.cc (maybe_push_to_top_level): For a non-lambda,
don't push to top level if decl_function_context is non-null.
* pt.cc (maybe_instantiate_noexcept): Use maybe_push_to_top_level.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/noexcept85.C: New test.
* g++.dg/cpp0x/noexcept86.C: New test.
can_init_array_with_p is wrongly saying that the init for 's' here:
struct S {
int *list = arr;
int arr[];
};
struct A {
A() {}
S s[2]{};
};
is invalid. But as process_init_constructor_array says, for "non-constant
initialization of trailing elements with no explicit initializers" we use
a VEC_INIT_EXPR wrapped in a TARGET_EXPR, built in process_init_constructor.
Unfortunately we didn't have a test for this scenario so I didn't
realize can_init_array_with_p must handle it.
PR c++/114439
gcc/cp/ChangeLog:
* init.cc (can_init_array_with_p): Return true for a VEC_INIT_EXPR
wrapped in a TARGET_EXPR.
gcc/testsuite/ChangeLog:
* g++.dg/init/array65.C: New test.
