ranges::begin() isn't guaranteed to be equality-preserving for non-forward
ranges, so in cartesian_product_view::end we need to avoid needlessly
calling begin() on the first range (which could be non-forward) in the
case where __empty_tail is false as per its specification.

Since we're already using a variadic lambda to compute __empty_tail, we
might as well use that same lambda to build up the tuple of iterators
instead of building it separately via e.g. std::apply or __tuple_transform.

	PR libstdc++/107572

libstdc++-v3/ChangeLog:

	* include/std/ranges (cartesian_product_view::end): When
	building the tuple of iterators, avoid calling ranges::begin on
	the first range if __empty_tail is false.
	* testsuite/std/ranges/cartesian_product/1.cc (test07): New test.

libstdc++-v3/ChangeLog:

	PR libstdc++/108882
	* config/os/gnu-linux/ldbl-ieee128-extra.ver: Fix incorrect
	patterns.

The standard was unclear what happens with the transformation of a deduction
guide if the initial template argument deduction fails for a reason other
than not deducing all the arguments; my implementation assumed that the
right thing was to give up on the deduction guide.  But in consideration of
CWG2664 this week I realized that we get a better result by just continuing
with an empty set of deductions, so the alias deduction guide is the same as
the original deduction guide plus the deducible constraint.

	DR 2664
	PR c++/102529

gcc/cp/ChangeLog:

	* pt.cc (alias_ctad_tweaks): Continue after deduction failure.

gcc/testsuite/ChangeLog:

	* g++.dg/DRs/dr2664.C: New test.
	* g++.dg/cpp2a/class-deduction-alias15.C: New test.

In my initial implementation of alias CTAD, I described a couple of
differences from the specification that I thought would not have a practical
effect; this testcase demonstrates that I was wrong.  One difference is
resolved by the CPTK_IS_DEDUCIBLE commit; the other (adding too many of the
alias template parameters to the new deduction guide) is fixed by this
patch.

	PR c++/105841

gcc/cp/ChangeLog:

	* pt.cc	(corresponding_template_parameter_list): Split out...
	(corresponding_template_parameter): ...from here.
	(find_template_parameters): Factor out...
	(find_template_parameter_info::find_in): ...this function.
	(find_template_parameter_info::find_in_recursive): New.
	(find_template_parameter_info::found): New.
	(alias_ctad_tweaks): Only add parms used in the deduced args.

gcc/testsuite/ChangeLog:

	* g++.dg/cpp2a/class-deduction-alias14.C: New test.

Co-authored-by: Michael Spertus <mike@spertus.com>

I want to have more discussion about the interface before claiming the
__is_deducible name, so for GCC 13 make it internal-only.

gcc/ChangeLog:

	* doc/extend.texi: Comment out __is_deducible docs.

gcc/cp/ChangeLog:

	* cp-trait.def (IS_DEDUCIBLE): Add space to name.

gcc/testsuite/ChangeLog:

	* g++.dg/ext/is_deducible1.C: Guard with
	__has_builtin (__is_deducible).

C++20 class template argument deduction for an alias template involves
adding a constraint that the template arguments for the alias template can
be deduced from the return type of the deduction guide for the underlying
class template.  In the standard, this is modeled as defining a class
template with a partial specialization, but it's much more efficient to
implement with a trait that directly tries to perform the deduction.

The first argument to the trait is a template rather than a type, so various
places needed to be adjusted to accommodate that.

	PR c++/105841

gcc/ChangeLog:

	* doc/extend.texi (Type Traits):: Document __is_deducible.

gcc/cp/ChangeLog:

	* cp-trait.def (IS_DEDUCIBLE): New.
	* cxx-pretty-print.cc (pp_cxx_trait): Handle non-type.
	* parser.cc (cp_parser_trait): Likewise.
	* tree.cc (cp_tree_equal): Likewise.
	* pt.cc (tsubst_copy_and_build): Likewise.
	(type_targs_deducible_from): New.
	(alias_ctad_tweaks): Use it.
	* semantics.cc (trait_expr_value): Handle CPTK_IS_DEDUCIBLE.
	(finish_trait_expr): Likewise.
	* constraint.cc (diagnose_trait_expr): Likewise.
	* cp-tree.h (type_targs_deducible_from): Declare.

gcc/testsuite/ChangeLog:

	* g++.dg/ext/is_deducible1.C: New test.

Compile a resource object that contains the utf8 manifest.

Then link that object into the driver and compiler proper.

For compiler proper the link has to be forced because the
resource object file gets into a static library (libbackend.a)
and gets eventually dropped because it has no symbols of
its own and nothing is referencing it inside the library.

Therefore, an artificial symbol is planted to force the link.

gcc/ChangeLog:

	PR driver/108865
	* config.host: add object for x86_64-*-mingw*.
	* config/i386/sym-mingw32.cc: dummy file to attach
	symbol.
	* config/i386/utf8-mingw32.rc: windres resource file.
	* config/i386/winnt-utf8.manifest: XML manifest to
	enable UTF-8.
	* config/i386/x-mingw32: reference to x-mingw32-utf8.
	* config/i386/x-mingw32-utf8: Makefile fragment to
	embed UTF-8 manifest.

Signed-off-by: Jonathan Yong <10walls@gmail.com>

LRA is too conservative in calculation of conflicts with clobbered regs by
using the biggest access mode.  This results in failure of possible reg
coalescing and worse code.  This patch solves the problem.

        PR rtl-optimization/108999

gcc/ChangeLog:

	* lra-constraints.cc (process_alt_operands): Use operand modes for
	clobbered regs instead of the biggest access mode.

gcc/testsuite/ChangeLog:

	* gcc.target/aarch64/pr108999.c: New.

The following plugs one place in extract_muldiv where it should avoid
folding when sanitizing overflow.

	PR middle-end/108995
	* fold-const.cc (extract_muldiv_1): Avoid folding
	(CST * b) / CST2 when sanitizing overflow and we rely on
	overflow being undefined.

	* gcc.dg/ubsan/pr108995.c: New testcase.

The following testcase is reduced from miscompilation of scipy package.
If we have say lhs = [1., 1.] - [1., 1.] and want to compute the range
of lhs from it, we correctly determine it is [0., 0.] (if computations
are exact, we generally don't try to round them further in
frange_arithmetic).  In the testcase it is about a reverse operation,
[1., 1.] = op1 + [1., 1.] and we want to compute range of op1 from that.
Right now we just perform the inverse operation (there are some corner
cases about NaN and infinities handling) and so arrive to range
[0., 0.] as well, and because it is a singleton, optimize return eps;
to return 0.  That is incorrect though, for the reverse ops we need to
take into account also rounding, the right exact range is
[-0x1.0p-54, 0x1.0p-53] in this case when rounding to nearest, i.e.
all numbers which added to 1. with round to nearest still produce 1.

The problem isn't solely on singleton ranges, and isn't solely on
results around zero.  We basically need to consider also values
where the result is up to 0.5ulp away from the lhs range boundaries
in each direction.

The following patch fixes it by extending the lhs range for the
reverse operations by 1ulp in each direction.  The PR contains
a pseudo-random test generator I've used to generate 300000 tests
of + and - and then used the same test with * and / instead of + and -
together with a hack to print the discovered ranges by the patch in
a form that another test could then verify the range is conservatively
correct and how far it is from a minimal range.

I believe the results are good enough for now, though plan to look
incrementally into trying to do something better on the -XXX_MAX or
XXX_MAX boundaries (where I think frange_nextafter will use -inf or +inf)
and also try to increase the range just by 0.5ulp rather than 1ulp
if !flag_rounding_math.  But dunno if either of those will be doable
and will pass the testing, so I think it is worth committing this fix
first.

2023-03-09  Jakub Jelinek  <jakub@redhat.com>
	    Richard Biener  <rguenther@suse.de>

	PR tree-optimization/109008
	* range-op-float.cc (float_widen_lhs_range): New function.
	(foperator_plus::op1_range, foperator_minus::op1_range,
	foperator_minus::op2_range, foperator_mult::op1_range,
	foperator_div::op1_range, foperator_div::op2_range): Use it.

	* gcc.c-torture/execute/ieee/pr109008.c: New test.

When OMP_WAIT_POLICY is not specified, current implementation will cause
icv flag GOMP_ICV_WAIT_POLICY unset, so global variable wait_policy
will remain its uninitialized value. Initialize it to -1 to make
GOMP_SPINCOUNT behavior consistent with its description.

libgomp/ChangeLog:

	PR libgomp/109062
	* env.c (wait_policy): Initialize to -1.
	(initialize_icvs): Initialize icvs->wait_policy to -1.
	* testsuite/libgomp.c-c++-common/pr109062.c: New test.

libgomp/ChangeLog:

	* libgomp.texi (Offload-Target Specifics): Mention GCN_STACK_SIZE.

As PR108727 shows, when cleanup code called by the stack
unwinder calls function _Unwind_Resume, it goes via plt
stub like:

   function 00000000.plt_call._Unwind_Resume:

=> 0x0000000010003580 <+0>:     std     r2,40(r1)
   0x0000000010003584 <+4>:     ld      r12,-31760(r2)
   0x0000000010003588 <+8>:     mtctr   r12
   0x000000001000358c <+12>:    ld      r2,-31752(r2)
   0x0000000010003590 <+16>:    cmpldi  r2,0
   0x0000000010003594 <+20>:    bnectr+
   0x0000000010003598 <+24>:    b       0x100031a4
                                        <_Unwind_Resume@plt>

It wants to save TOC base (r2) to r1 + 40, but we only
bump the stack segment by 32 bytes as follows:

   stdu %r29,-32(%r3)

It means the access is out of the stack segment allocated
by __generic_morestack, once the touch area isn't writable
like this failure shows, it would cause segment fault.

So fix the bump size with one reasonable value PARAMS.

	PR libgcc/108727

libgcc/ChangeLog:

	* config/rs6000/morestack.S (__morestack): Use PARAMS for new stack
	bump size.

According to Haochen's finding in [1], currently ppc-fortran.exp
doesn't support Fortran specific warning or error messages well.
By looking into it, it's due to that gfortran uses some different
warning/error prefixes as follows:

    set gcc_warning_prefix "\[Ww\]arning:"
    set gcc_error_prefix "(Fatal )?\[Ee\]rror:"

comparing to:

    set gcc_warning_prefix "warning:"
    set gcc_error_prefix "(fatal )?error:"

So this is to override these two prefixes and make it support
dg-{warning,error} checks.

[1] https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613302.html

gcc/testsuite/ChangeLog:

	* gcc.target/powerpc/ppc-fortran/ppc-fortran.exp: Override
	gcc_{warning,error}_prefix with Fortran specific one used in
	gfortran_init.

Test cases scalar-test-data-class-1[45].c adopts type __int128
which requires to check int128 effective target, otherwise the
testing on them will fail at -m32.  This patch is to add int128
effective target requirement.

gcc/testsuite/ChangeLog:

	* gcc.target/powerpc/bfp/scalar-test-data-class-14.c: Adjust with
	int128 effective target requirement.
	* gcc.target/powerpc/bfp/scalar-test-data-class-15.c: Likewise.

Two test cases scalar-test-data-class-12.c and vec-test-data-class-9.c
fail on Power9 BE testing at -m32, they adopts a built-in function
scalar_insert_exp which requires powerpc64 support.  This patch
is to make them to check has_arch_ppc64 effective target requirement.

	PR testsuite/108729

gcc/testsuite/ChangeLog:

	* gcc.target/powerpc/bfp/scalar-test-data-class-12.c: Adjust with
	has_arch_ppc64 effective target.
	* gcc.target/powerpc/bfp/vec-test-data-class-9.c: Likewise.

The built-in function scalar_test_neg_qp is under stanza
ieee128-hw, that is TARGET_FLOAT128_HW.  Since we don't
have float128 hardware support on 32-bit as follows:

if (TARGET_FLOAT128_HW && !TARGET_64BIT)
  {
    if ((rs6000_isa_flags_explicit & OPTION_MASK_FLOAT128_HW) != 0)
      error ("%qs requires %qs", "%<-mfloat128-hardware%>", "-m64");
    rs6000_isa_flags &= ~OPTION_MASK_FLOAT128_HW;
  }

So adjust the case with lp64 effective target accordingly.

	PR testsuite/108730

gcc/testsuite/ChangeLog:

	* gcc.target/powerpc/bfp/scalar-test-neg-8.c: Adjust with lp64
	effective target requirement.

Compiled with cpu type Power9 or later, GCC generates
xxspltib rather than vspltis*, so adjust the test
case scanning content accordingly.

	PR testsuite/108813

gcc/testsuite/ChangeLog:

	* gcc.target/powerpc/pr101384-2.c: Adjust with xxspltib.

On BE, the extracted index for the leftmost element is 0
rather than 1, adjust the test case accordingly.

	PR testsuite/108810

gcc/testsuite/ChangeLog:

	* gcc.target/powerpc/fold-vec-extract-double.p9.c (testd_cst): Adjust
	the extracted index for BE.

The mips msa-ds.c test is trying to ensure that MSA branches can have their
delay slots filled.  The regexp it used looked for the function name, a nop,
then the function name again.  If found that sequence, then the test failed.

The problem is with Vlad's recent IRA work there's simply less code in the
test (good) and as a result one of the *other* branches in the test had an
unfilled delay slot -- the delay slot for the MSA branch was still being
filled.

This patch tightens up the regexp.  In particular it looks for the MSA branch
and a nop on the next line (avoiding the over-eager .* construct).  That
indicates that the MSA branch did not have its delay slot filled.  When that
sequence is found, then the test fails.

This fixes the recent regressions for mips64 and mips64el in the tester.

Installing on the trunk,

gcc/testsuite:
	* gcc.target/mips/msa-ds.c: Fix over eager pattern matching.

The recently added tests missed checking for "fopenmp" (see
other tests where "-fopenmp" is passed), which makes them
fail on non-openmp systems.

	* gcc.dg/analyzer/omp-parallel-for-get-min.c,
	gcc.dg/analyzer/omp-parallel-for-1.c: Require effective target fopenmp.

gcc/ChangeLog

	PR sanitizer/81649
	* doc/invoke.texi (Instrumentation Options):  Clarify
	LeakSanitizer behavior.

gcc/ChangeLog
	* doc/install.texi (Prerequisites): Add link to gmplib.org.

A missed piece of the patch for static operator(): in tsubst_function_decl,
we don't want to replace the first parameter with a new closure pointer if
operator() is static.

	PR c++/108526
	PR c++/106651

gcc/cp/ChangeLog:

	* pt.cc (tsubst_function_decl): Don't replace the closure
	parameter if DECL_STATIC_FUNCTION_P.

gcc/testsuite/ChangeLog:

	* g++.dg/cpp23/static-operator-call5.C: Pass -g.

This updates baseline_symbols.txt for the Fedora 39 arches.
Most of the added symbols are added to all 5 files, exceptions are
DF16_ rtti stuff (only added on x86 and aarch64 which supports those),
DF16b rtti stuff (only x86 right now), _M_replace_cold (m vs. j
differences), DF128_ charconv (only x86), GLIBCXX_LDBL_3.4.31
symver (s390x), _M_get_sys_info/_M_get_local_info (l vs. x).
I was using
grep ^+ | sed 's/OBJECT:[0-9]*:/OBJECT:/' | sort | uniq -c | sort -n | less
on the patch to analyze.
powerpc64le-linux not included because I'll need to regenerate it.

2023-03-07  Jakub Jelinek  <jakub@redhat.com>

	* config/abi/post/x86_64-linux-gnu/baseline_symbols.txt: Update.
	* config/abi/post/x86_64-linux-gnu/32/baseline_symbols.txt: Update.
	* config/abi/post/i486-linux-gnu/baseline_symbols.txt: Update.
	* config/abi/post/aarch64-linux-gnu/baseline_symbols.txt: Update.
	* config/abi/post/s390x-linux-gnu/baseline_symbols.txt: Update.

libstdc++-v3/ChangeLog:

	PR libstdc++/108882
	* config/abi/pre/gnu.ver (GLIBCXX_3.4.31): Adjust patterns to
	not match symbols in namespace std::__gnu_cxx11_ieee128.
	* config/os/gnu-linux/ldbl-ieee128-extra.ver: Add patterns for
	std::__gnu_cxx11_ieee128::money_{get,put}.

libstdc++-v3/ChangeLog:

	* libsupc++/eh_personality.cc: Fix spelling in comment.

Here, -Wdangling-reference triggers where it probably shouldn't, causing
some grief.  The code in question uses a reference wrapper with a member
function returning a reference to a subobject of a non-temporary object:

  const Plane & meta = fm.planes().inner();

I've tried a few approaches, e.g., checking that the member function's
return type is the same as the type of the enclosing class (which is
the case for member functions returning *this), but that then breaks
Wdangling-reference4.C with std::optional<std::string>.

This patch adjusts do_warn_dangling_reference so that we look through
reference wrapper classes (meaning, has a reference member and a
constructor taking the same reference type, or is std::reference_wrapper
or std::ranges::ref_view) and don't warn for them, supposing that the
member function returns a reference to a non-temporary object.

	PR c++/107532

gcc/cp/ChangeLog:

	* call.cc (reference_like_class_p): New.
	(do_warn_dangling_reference): Add new bool parameter.  See through
	reference_like_class_p.

gcc/testsuite/ChangeLog:

	* g++.dg/warn/Wdangling-reference8.C: New test.
	* g++.dg/warn/Wdangling-reference9.C: New test.

This fixes another syntax error in slp-3.c.  I missed a '{ ... }' in
order to properly exclude s390_vx.

gcc/testsuite/ChangeLog:

	* gcc.dg/vect/slp-3.c: Add '{ ... }'.

In my recent rtti.cc change I assumed when emitting the support tinfos
that the tinfos for the fundamental types haven't been created yet.
Normally (in libsupc++.a (fundamental_type_info.o)) that is the case,
but as can be seen on the testcase, one can violate it by using typeid
etc. in the same TU and do it before ~__fundamental_type_info ()
definition.

The following patch fixes that by popping from unemitted_tinfo_decls
only in the normal case when it is there, and treating non-NULL
DECL_INITIAL on a tinfo node as indication that emit_tinfo_decl has
processed it already.

2023-03-07  Jakub Jelinek  <jakub@redhat.com>

	PR c++/109042
	* rtti.cc (emit_support_tinfo_1): Don't assert that last
	unemitted_tinfo_decls element is tinfo, instead pop from it only in
	that case.
	* decl2.cc (c_parse_final_cleanups): Don't call emit_tinfo_decl
	for unemitted_tinfO_decls which have already non-NULL DECL_INITIAL.

	* g++.dg/rtti/pr109042.C: New test.

When processing a noexcept, constructors aren't elided: build_over_call
has
	 /* It's unsafe to elide the constructor when handling
	    a noexcept-expression, it may evaluate to the wrong
	    value (c++/53025).  */
	 && (force_elide || cp_noexcept_operand == 0))
so the assert I added recently needs to be relaxed a little bit.

	PR c++/109030

gcc/cp/ChangeLog:

	* constexpr.cc (cxx_eval_call_expression): Relax assert.

gcc/testsuite/ChangeLog:

	* g++.dg/cpp0x/noexcept77.C: New test.

Similarly to PR107938, this also started with r11-557, whereby cp_finish_decl
can call check_initializer even in a template for a constexpr initializer.

Here we are rejecting

  extern const Q q;

  template<int>
  constexpr auto p = q(0);

even though q has a constexpr operator().  It's deemed non-const by
decl_maybe_constant_var_p because even though 'q' is const it is not
of integral/enum type.

If fun is not a function pointer, we don't know if we're using it as an
lvalue or rvalue, so with this patch we pass 'any' for want_rval.  With
that, p_c_e/VAR_DECL doesn't flat out reject the underlying VAR_DECL.

	PR c++/107939

gcc/cp/ChangeLog:

	* constexpr.cc (potential_constant_expression_1) <case CALL_EXPR>: Pass
	'any' when recursing on a VAR_DECL and not a pointer to function.

gcc/testsuite/ChangeLog:

	* g++.dg/cpp1y/var-templ74.C: Remove dg-error.
	* g++.dg/cpp1y/var-templ77.C: New test.

Fix the bug of the rvv bool mode precision with the adjustment.
The bits size of vbool*_t will be adjusted to
[1, 2, 4, 8, 16, 32, 64] according to the rvv spec 1.0 isa. The
adjusted mode precison of vbool*_t will help underlying pass to
make the right decision for both the correctness and optimization.

Given below sample code:

void test_1(int8_t * restrict in, int8_t * restrict out)
{
  vbool8_t v2 = *(vbool8_t*)in;
  vbool16_t v5 = *(vbool16_t*)in;
  *(vbool16_t*)(out + 200) = v5;
  *(vbool8_t*)(out + 100) = v2;
}

Before the precision adjustment:

addi    a4,a1,100
vsetvli a5,zero,e8,m1,ta,ma
addi    a1,a1,200
vlm.v   v24,0(a0)
vsm.v   v24,0(a4)
// Need one vsetvli and vlm.v for correctness here.
vsm.v   v24,0(a1)

After the precision adjustment:

csrr    t0,vlenb
slli    t1,t0,1
csrr    a3,vlenb
sub     sp,sp,t1
slli    a4,a3,1
add     a4,a4,sp
sub     a3,a4,a3
vsetvli a5,zero,e8,m1,ta,ma
addi    a2,a1,200
vlm.v   v24,0(a0)
vsm.v   v24,0(a3)
addi    a1,a1,100
vsetvli a4,zero,e8,mf2,ta,ma
csrr    t0,vlenb
vlm.v   v25,0(a3)
vsm.v   v25,0(a2)
slli    t1,t0,1
vsetvli a5,zero,e8,m1,ta,ma
vsm.v   v24,0(a1)
add     sp,sp,t1
jr      ra

However, there may be some optimization opportunates after
the mode precision adjustment. It can be token care of in
the RISC-V backend in the underlying separted PR(s).

gcc/ChangeLog:

	PR target/108185
	PR target/108654
	* config/riscv/riscv-modes.def (ADJUST_PRECISION): Adjust VNx*BI
	modes.
	* config/riscv/riscv.cc (riscv_v_adjust_precision): New.
	* config/riscv/riscv.h (riscv_v_adjust_precision): New.
	* genmodes.cc (adj_precision): New.
	(ADJUST_PRECISION): New.
	(emit_mode_adjustments): Handle ADJUST_PRECISION.

gcc/testsuite/ChangeLog:

	PR target/108185
	PR target/108654
	* gcc.target/riscv/rvv/base/pr108185-1.c: New test.
	* gcc.target/riscv/rvv/base/pr108185-2.c: New test.
	* gcc.target/riscv/rvv/base/pr108185-3.c: New test.
	* gcc.target/riscv/rvv/base/pr108185-4.c: New test.
	* gcc.target/riscv/rvv/base/pr108185-5.c: New test.
	* gcc.target/riscv/rvv/base/pr108185-6.c: New test.
	* gcc.target/riscv/rvv/base/pr108185-7.c: New test.
	* gcc.target/riscv/rvv/base/pr108185-8.c: New test.

Signed-off-by: Pan Li <pan2.li@intel.com>
Co-authored-by: Ju-Zhe Zhong <juzhe.zhong@rivai.ai>

Stack protector needs a guard value on the stack and change the stack
layout.  So we need to disable it for those tests, to avoid test failure
with --enable-default-ssp.

gcc/testsuite/ChangeLog:

	* gcc.target/aarch64/shrink_wrap_1.c (dg-options): Add
	-fno-stack-protector.
	* gcc.target/aarch64/stack-check-cfa-1.c (dg-options): Add
	-fno-stack-protector.
	* gcc.target/aarch64/stack-check-cfa-2.c (dg-options): Add
	-fno-stack-protector.
	* gcc.target/aarch64/test_frame_17.c (dg-options): Add
	-fno-stack-protector.

Storing stack guarding variable need one stp instruction, breaking the
scan-assembler-not pattern in the test.  Disable stack protector to
avoid a test failure with --enable-default-ssp.

gcc/testsuite/ChangeLog:

	* gcc.target/aarch64/pr104005.c (dg-options): Add
	-fno-stack-protector.

The test scans for "const_int 0" in the RTL dump, but stack protector
can produce more "const_int 0".  To avoid a failure with
--enable-default-ssp, disable stack protector for this.

gcc/testsuite/ChangeLog:

	* gcc.target/aarch64/auto-init-7.c (dg-options): Add
	-fno-stack-protector.

Stack protector influence code generation and cause function body checks
fail.

gcc/testsuite/ChangeLog:

	* gcc.target/aarch64/pr103147-10.c (dg-options): Add
	-fno-stack-protector.
	* g++.target/aarch64/pr103147-10.C: Likewise.

If GCC is configured with --enable-default-ssp, the stack protector can
make many sve-pcs tests fail.

gcc/testsuite/ChangeLog:

	* gcc.target/aarch64/sve/pcs/aarch64-sve-pcs.exp (sve_flags):
	Add -fno-stack-protector.