The millicode division and remainder routines trap division by zero.
The unwinder needs these directives to unwind divide by zero traps.

2023-04-05  John David Anglin  <danglin@gcc.gnu.org>

libgcc/ChangeLog:

	PR target/109374
	* config/pa/milli64.S (RETURN_COLUMN): Define.
	($$divI): Add CFI directives.
	($$divU): Likewise.
	($$remI): Likewise.
	($$remU): Likewise.

PR 108959 shows one more example where undefined code with type
incompatible accesses to stuff passed in parameters can cause an ICE
because we try to create a VIEW_CONVERT_EXPR of mismatching sizes:

1. IPA-CP tries to push one type from above,

2. IPA-SRA (correctly) decides the parameter is useless because it is
   only used to construct an argument to another function which does not
   use it and so the formal parameter should be removed,

3. but the code reconciling IPA-CP and IPA-SRA transformations still
   wants to perform the IPA-CP and overrides the built-in DCE of
   useless statements and tries to stuff constants into them
   instead, constants of a type with mismatching type and size.

This patch avoids the situation in IPA-SRA by purging the IPA-CP
results from any "aggregate" constants that are passed in parameters
which are detected to be useless.  It also removes IPA value range and
bits information associated with removed parameters stored in the same
structure so that the useless information is not streamed later on.

gcc/ChangeLog:

2023-03-22  Martin Jambor  <mjambor@suse.cz>

	PR ipa/108959
	* ipa-sra.cc (zap_useless_ipcp_results): New function.
	(process_isra_node_results): Call it.

gcc/testsuite/ChangeLog:

2023-03-17  Martin Jambor  <mjambor@suse.cz>

	PR ipa/108959
	* gcc.dg/ipa/pr108959.c: New test.

It's quite obvious that the order of vrsub SEW64 is wrong.

gcc/ChangeLog:

	* config/riscv/vector.md: Fix incorrect operand order.

gcc/testsuite/ChangeLog:

	* g++.target/riscv/rvv/base/bug-23.C: New test.

This was approved at the C++ meeting in February.

libstdc++-v3/ChangeLog:

	* include/bits/regex.h (sub_match::swap): New function.
	* testsuite/28_regex/sub_match/lwg3204.cc: New test.

        PR 109399

gcc/ChangeLog:

	* config/riscv/riscv-vsetvl.cc
	(pass_vsetvl::compute_local_backward_infos): Update user vsetvl in local
	demand fusion.

gcc/testsuite/ChangeLog:

	* gcc.target/riscv/rvv/vsetvl/pr109399.c: New test.

gcc/ChangeLog:

	* config/riscv/riscv-vector-builtins.def: Fix typo.
	* config/riscv/riscv.cc (riscv_dwarf_poly_indeterminate_value): Ditto.
	* config/riscv/vector-iterators.md: Ditto.

The line-break in the example looked odd, even more so with
a page-break in the middle of it, due to recently added text
in preceding pages.

	* doc/md.texi (Including Patterns): Fix page break.

	* gcc.pot: Regenerate.

gcc/fortran/ChangeLog:

	PR fortran/104349
	* expr.cc (check_restricted): Adjust check for valid variables in
	restricted expressions: make no exception for module variables.

gcc/testsuite/ChangeLog:

	PR fortran/104349
	* gfortran.dg/der_charlen_1.f90: Adjust dg-patterns.
	* gfortran.dg/pr104349.f90: New test.

I've missed one of my recent range-op-float.cc changes (likely the
r13-6967 one) caused
FAIL: libphobos.phobos/std/math/algebraic.d execution test
FAIL: libphobos.phobos_shared/std/math/algebraic.d execution test
regressions, distilled into a C testcase below.

In the testcase, we have
!(u >= v)
condition where both u and v are results of fabs*, which guards
t1 = u u<= __FLT_MAX__;
and
t2 = v u<= __FLT_MAX__;
comparisons.  From false u >= v where u and v have [0.0, +Inf] NAN
ranges we (incorrectly deduce that one of them is [nextafterf (0.0, 1.0), +Inf] NAN
and the other is [0.0, nextafterf (+Inf, 0.0)] NAN and from that deduce that
one of the comparisons is always true, because UNLE_EXPR with the maximum
representable number are false only if the value is +Inf and our ranges tell
that is not possible.

The bug is that the u >= v comparison determines a sensible range only when
it is true - we then know neither operand can be NAN and it behaves
correctly.  But when the comparison is false, our current code gives
sensible answers only if the other op can't be NAN.  If it can be NAN,
whenever it is NAN, the comparison is always false regardless of the other
value, so the other value needs to be VARYING.
Now, foperator_unordered_lt::op1_range etc. had code to deal with that
for op?.known_nan (), but as the testcase shows, it is enough if it may be a
NAN at runtime to make it VARYING.

So, the following patch replaces for all those BRS_FALSE cases of the normal
non-equality comparisons if (opOTHER.known_isnan ()) r.set_varying (type);
to do it also if maybe_isnan ().

For the unordered or ... comparisons, it is similar for BRS_TRUE.  Those
comparisons are true whenever either operand is NAN, or if neither is NAN,
the corresponding normal comparison.  So, if those comparisons are true
and other operand might be a NAN, we can't tell (VARYING), if it is false,
currently handling is correct.

2023-04-04  Jakub Jelinek  <jakub@redhat.com>

	PR tree-optimization/109386
	* range-op-float.cc (foperator_lt::op1_range, foperator_lt::op2_range,
	foperator_le::op1_range, foperator_le::op2_range,
	foperator_gt::op1_range, foperator_gt::op2_range,
	foperator_ge::op1_range, foperator_ge::op2_range): Make r varying for
	BRS_FALSE case even if the other op is maybe_isnan, not just
	known_isnan.
	(foperator_unordered_lt::op1_range, foperator_unordered_lt::op2_range,
	foperator_unordered_le::op1_range, foperator_unordered_le::op2_range,
	foperator_unordered_gt::op1_range, foperator_unordered_gt::op2_range,
	foperator_unordered_ge::op1_range, foperator_unordered_ge::op2_range):
	Make r varying for BRS_TRUE case even if the other op is maybe_isnan,
	not just known_isnan.

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

Here we're failing to detect a signed overflow with -O because match.pd,
since r8-1516, transforms

  c = (a + 1) - (int) (short int) b;

into

  c = (int) ((unsigned int) a + 4294946117);

wrongly eliding the overflow.  This kind of problems is usually
avoided by using TYPE_OVERFLOW_SANITIZED in the appropriate place.
The first match.pd hunk in the patch fixes it.  I've constructed
a testcase for each of the surrounding cases as well.  Then I
noticed that fold_binary_loc/associate has the same problem, so I've
added a TYPE_OVERFLOW_SANITIZED there as well (it may be too coarse,
sorry).  Then I found yet another problem, but instead of fixing it
now I've opened 109134.  I could probably go on and find a dozen more.

	PR sanitizer/109107

gcc/ChangeLog:

	* fold-const.cc (fold_binary_loc): Use TYPE_OVERFLOW_SANITIZED
	when associating.
	* match.pd: Use TYPE_OVERFLOW_SANITIZED.

gcc/testsuite/ChangeLog:

	* c-c++-common/ubsan/pr109107-1.c: New test.
	* c-c++-common/ubsan/pr109107-2.c: New test.
	* c-c++-common/ubsan/pr109107-3.c: New test.
	* c-c++-common/ubsan/pr109107-4.c: New test.

From the initial merge of the MVE backend, the vcreate
intrinsic has had the vector lanes mixed up, compared
to the intended (as per the ACLE) definition. This is
also a discrepancy with clang:
https://godbolt.org/z/4n93e5aqj

This patches simply switches the operands around and
makes the tests more specific on the input registers
(I do not touch the output Q regs as they vary based
on softfp/hardfp or the input registers when the input
is a constant, since, in that case, a single register
is loaded with a constant and then the same register is
used twice as "vmov q0[2], q0[0], r2, r2" and the reg
num might not always be guaranteed).

gcc/ChangeLog:

	* config/arm/mve.md (mve_vcvtq_n_to_f_<supf><mode>): Swap operands.
	(mve_vcreateq_f<mode>): Swap operands.

gcc/testsuite/ChangeLog:

	* gcc.target/arm/mve/intrinsics/vcreateq_f16.c: Tighten test.
	* gcc.target/arm/mve/intrinsics/vcreateq_f32.c: Tighten test.
	* gcc.target/arm/mve/intrinsics/vcreateq_s16.c: Tighten test.
	* gcc.target/arm/mve/intrinsics/vcreateq_s32.c: Tighten test.
	* gcc.target/arm/mve/intrinsics/vcreateq_s64.c: Tighten test.
	* gcc.target/arm/mve/intrinsics/vcreateq_s8.c: Tighten test.
	* gcc.target/arm/mve/intrinsics/vcreateq_u16.c: Tighten test.
	* gcc.target/arm/mve/intrinsics/vcreateq_u32.c: Tighten test.
	* gcc.target/arm/mve/intrinsics/vcreateq_u64.c: Tighten test.
	* gcc.target/arm/mve/intrinsics/vcreateq_u8.c: Tighten test.

The string returned by std::bad_exception::what() hasn't been a mangled
name since PR libstdc++/14493 was fixed for GCC 4.2.0, so remove the
docs showing how to demangle it.

libstdc++-v3/ChangeLog:

	* doc/xml/manual/extensions.xml: Remove std::bad_exception from
	example program.
	* doc/html/manual/ext_demangling.html: Regenerate.

gcc/ChangeLog:

	* config/gcn/gcn-valu.md (one_cmpl<mode>2<exec>): New.

The following patch unbreaks riscv bootstrap, where it previously failed
on -Werror=format-diag warning promoted to error.

Ok for trunk?

Or shall it say e.g.
"%<-march=%s%>: %<zfinx%> extension conflicts with %<f>"
?
Or say if the current condition is true, do
const char *ext = "zfinx";
if (subset_list->lookup ("zdinx"))
  ext = "zdinx";
else if (subset_list->lookup ("zhinx"))
  ext = "zhinx";
else if (subset_list->lookup ("zhinxmin"))
  ext = "zhinxmin";
and
"%<-march=%s%>: %qs extension conflicts with %<f>", arch, ext
?  Or do similar check for which extension to print against it,
const char *ext = "zfinx";
const char *ext2 = "f";
if (subset_list->lookup ("zdinx"))
  {
    ext = "zdinx";
    if (subset_list->lookup ("d"))
      ext2 = "d";
  }
else if (subset_list->lookup ("zhinx"))
  {
    ext = "zhinx";
    if (subset_list->lookup ("zfh"))
      ext2 = "zfh";
  }
else if (subset_list->lookup ("zhinxmin"))
  {
    ext = "zhinxmin";
    if (subset_list->lookup ("zfhmin"))
      ext2 = "zfhmin";
  }
"%<-march=%s%>: %qs extension conflicts with %qs", arch, ext, ext2
?

2023-04-04  Jakub Jelinek  <jakub@redhat.com>

	PR target/109384
	* common/config/riscv/riscv-common.cc (riscv_subset_list::parse):
	Reword diagnostics about zfinx conflict with f, formatting fixes.

	* gcc.target/riscv/arch-19.c: Expect a different message about zfinx
	vs. f conflict.

libpthread has been folded into libc since Solaris 10 and replaced by a
filter on libc.  Linking with libpthread thus only creates unnecessary
runtime overhead.

This patch thus removes linking with -lpthread if -pthread/-pthreads is
specified, thus getting rid of the libpthread dependency in libatomic,
libgdruntime, libgomp, libgphobos, and libitm.

Bootstrapped without regressions on i386-pc-solaris2.11 and
sparc-sun-solaris2.11 (both Solaris 11.3 and 11.4).

2023-04-03  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

	gcc:
	* config/sol2.h (LIB_SPEC): Don't link with -lpthread.

When adjusting calls to reflect instrumentation we failed to handle
calls to aliases since they appear to have no body.  Instead resort
to symtab node availability.  The patch also avoids touching
internal function calls in a more obvious way (builtins might
have a body available).

profiledbootstrap & regtest running on x86_64-unknown-linux-gnu.

Honza - does this look OK?

	PR tree-optimization/109304
	* tree-profile.cc (tree_profiling): Use symtab node
	availability to decide whether to skip adjusting calls.
	Do not adjust calls to internal functions.

	* gcc.dg/pr109304.c: New testcase.

As PR108807 exposes, the current handling in function
rs6000_expand_vector_set_var_p9 doesn't take care of big
endianness.  Currently the function is to rotate the
target vector by moving element to-be-set to element 0,
set element 0 with the given val, then rotate back.  To
get the permutation control vector for the rotation, it
makes use of lvsr and lvsl, but the element ordering is
different for BE and LE (like element 0 is the most
significant one on BE while the least significant one on
LE), this patch is to add consideration for BE and make
sure permutation control vectors for rotations are expected.

As tested, it helped to fix the below failures:

FAIL: gcc.target/powerpc/pr79251-run.p9.c execution test
FAIL: gcc.target/powerpc/pr89765-mc.c execution test
FAIL: gcc.target/powerpc/vsx-builtin-10d.c execution test
FAIL: gcc.target/powerpc/vsx-builtin-11d.c execution test
FAIL: gcc.target/powerpc/vsx-builtin-14d.c execution test
FAIL: gcc.target/powerpc/vsx-builtin-16d.c execution test
FAIL: gcc.target/powerpc/vsx-builtin-18d.c execution test
FAIL: gcc.target/powerpc/vsx-builtin-9d.c execution test
	PR target/108807

gcc/ChangeLog:

	* config/rs6000/rs6000.cc (rs6000_expand_vector_set_var_p9): Fix gen
	function for permutation control vector by considering big endianness.

The failures on the original failed case builtin-bitops-1.c
and the associated test case pr108699.c here show that the
current support of parity vector mode is wrong on Power.
The hardware insns vprtyb[wdq] which operate on the least
significant bit of each byte per element, they doesn't match
what RTL opcode parity needs, but the current implementation
expands it with them wrongly.

This patch is to fix the handling with one more insn vpopcntb.

	PR target/108699

gcc/ChangeLog:

	* config/rs6000/altivec.md (*p9v_parity<mode>2): Rename to ...
	(rs6000_vprtyb<mode>2): ... this.
	* config/rs6000/rs6000-builtins.def (VPRTYBD): Replace parityv2di2 with
	rs6000_vprtybv2di2.
	(VPRTYBW): Replace parityv4si2 with rs6000_vprtybv4si2.
	(VPRTYBQ): Replace parityv1ti2 with rs6000_vprtybv1ti2.
	* config/rs6000/vector.md (parity<mode>2 with VEC_IP): Expand with
	popcountv16qi2 and the corresponding rs6000_vprtyb<mode>2.

gcc/testsuite/ChangeLog:

	* gcc.target/powerpc/p9-vparity.c: Add scan-assembler-not for vpopcntb
	to distinguish parity byte from parity.
	* gcc.target/powerpc/pr108699.c: New test.

Here friend matching tries to find a matching non-template friend and fails,
so we mark the friend as a template specialization to be determined later.
Then cplus_decl_attributes tries again to find a matching function and gets
confused by DECL_TEMPLATE_INSTANTIATION without DECL_TEMPLATE_INFO.  But it
doesn't make sense for find_last_decl to be trying to match anything with
DECL_USE_TEMPLATE set; those are matched elsewhere.

	PR c++/107484

gcc/cp/ChangeLog:

	* decl2.cc (find_last_decl): Return early if DECL_USE_TEMPLATE.

gcc/testsuite/ChangeLog:

	* g++.dg/lookup/friend25.C: New test.

I needed to check what was allowed in a define_split, but
had problems understanding what was meant by "Splitting of
jump instruction into sequence that over by another jump
instruction".

	* doc/md.texi (Insn Splitting): Tweak wording for readability.

Co-Authored-By: Sandra Loosemore <sandra@codesourcery.com>

Now that we resolve non-dependent variable template-ids ahead of time,
cp_finish_decl needs to handle a new invalid situation: we can end up
trying to instantiate a variable template with deduced type before we
fully parsed its initializer.

	PR c++/109300

gcc/cp/ChangeLog:

	* decl.cc (cp_finish_decl): Diagnose ordinary auto deduction
	with no initializer, instead of asserting.

gcc/testsuite/ChangeLog:

	* g++.dg/cpp1y/var-templ79.C: New test.

	* sv.po: Update.

This patch removes an unused parameter 'module' from
DoVariableDeclaration in M2GCCDeclare.mod.  It also removes unused
procedures from PHBuild.bnf.

gcc/m2/ChangeLog:

	PR modula2/109388
	* gm2-compiler/M2GCCDeclare.mod (DoVariableDeclaration):
	Remove second parameter module.  Adjust all callers to
	remove the second parameter.
	* gm2-compiler/PHBuild.bnf (CheckAndInsert): Remove.
	(InStopSet): Remove.
	(PeepToken): Remove.
	(PushQualident): Remove.
	(SimpleDes): Remove.
	(ActualParameters): Remove.

Signed-off-by: Gaius Mulley <gaiusmod2@gmail.com>

We are in the process of changing data structures holding information
about constants passed by reference and in aggregates to use unsigned
int offsets rather than HOST_WIDE_INT (which was selected simply
because that is what fell out of get_ref_base_and_extent at that time)
in order to conserve memory, especially at WPA time.

PR 109303 testcase discovers that we do not properly check that we
only create jump functions with offsets (plus sizes) that fit into the
smaller type.  This patch adds the necessary check.

gcc/ChangeLog:

2023-03-30  Martin Jambor  <mjambor@suse.cz>

	PR ipa/109303
	* ipa-prop.cc (determine_known_aggregate_parts): Check that the
	offset + size will be representable in unsigned int.

gcc/testsuite/ChangeLog:

2023-03-30  Jakub Jelinek  <jakub@redhat.com>
	    Martin Jambor  <mjambor@suse.cz>

	PR ipa/109303
	* gcc.dg/pr109303.c: New test.

Recent Solaris 11.4 SRUs bundle zstd, but only the 64-bit libraries (no
idea why).  Because of this, in 32-bit builds cc1 etc. fail to link with
undefined references to various ZSTD_* functions from lto-compress.o.
This happens because currently only the presence of <zstd.h> is
necessary to enable zstd support in lto-compress.cc etc.

This patch checks for libzstd first and disables zstd support if
missing.

Tested on sparc-sun-solaris2.11 with the system installation of zstd
(64-bit only) and a locally-compiled one (specified with --with-zstd).

2023-03-28  Rainer Orth  <ro@CeBiTec.Uni-Bielefeld.DE>

	gcc:
	* configure.ac (ZSTD_LIB): Move before zstd.h check.
	Unset gcc_cv_header_zstd_h without libzstd.
	* configure: Regenerate.

gcc/ChangeLog:

	* doc/invoke.texi: Document new param.

gcc/
	* doc/sourcebuild.texi (const_volatile_readonly_section): Document
	new check_effective_target function.

gcc/ChangeLog:

	* config/riscv/riscv-vector-builtins.def (vuint32m8_t): Fix typo.
	(vfloat32m8_t): Likewise

gcc/testsuite/
	PR target/102146
	* gcc.target/powerpc/pr56605.c: Modify the match pattern for dump
	scan.

gcc/ChangeLog:

	* doc/md.texi: Document signbitm2.

Add hppa*-*-* to dg-additional-options list.

2023-04-02  John David Anglin  <danglin@gcc.gnu.org>

gcc/testsuite/ChangeLog:

	PR target/109375
	* gnat.dg/opt39.adb: Add hppa*-*-* to dg-additional-options list.

Test needs to be skipped if the target does not support atomic primitives.

2023-04-02  John David Anglin  <danglin@gcc.gnu.org>

gcc/testsuite/ChangeLog:

	PR target/109376
	* gnat.dg/prot7.adb: Skip on hppa.

This patch enables gm2 to pass -fmod= though to cc1gm2.  It also
builds the libraries for m2/stage2/cc1gm2 with no named path and
full debugging.

gcc/m2/ChangeLog:

	PR modula2/109336
	* Make-lang.in (GM2_O): Set to -O0.
	(GM2_LIBS): Remove target libraries and replace with build libs.
	(BUILD-LIBS): New declaration.
	(m2/gm2-libs/libgm2.a): New rule.
	(m2/gm2-libs/%.o): New rule.
	(m2/gm2-libs/choosetemp.o): New rule.
	* gm2-compiler/M2ColorString.mod (append): Use ADR rather than
	implicit conversion.
	* gm2-compiler/M2Comp.mod (Compile): Add qprintf messages for when
	a source file is not found.  Improve comments and formatting.
	* gm2-libs-ch/cgetopt.c (cgetopt_cgetopt_long): Remove
	ansi-decl.h.  Add getopt.h.
	(cgetopt_cgetopt_long_only): Change cgetopt_ to getopt_.
	* gm2spec.cc (lang_specific_driver): Do not skip -fmod=.
	Remove comment.

Signed-off-by: Gaius Mulley <gaiusmod2@gmail.com>

On Fri, Nov 13, 2020 at 11:53:43AM -0700, Jeff Law via Gcc-patches wrote:
>
> On 5/1/20 6:06 PM, Seija Kijin via Gcc-patches wrote:
> > The original code in libiberty says "FIXME" and then says it has not been
> > validated to be ANSI compliant. However, this patch changes the function to
> > match implementations that ARE compliant, and such code is in the public
> > domain.
> >
> > I ran the test results, and there are no test failures.
>
> Thanks.  This seems to be the standard "simple" strstr implementation. 
> There's significantly faster implementations available, but I doubt it's
> worth the effort as the version in this file only gets used if there is
> no system strstr.c.

Except that PR109306 says the new version is non-compliant and
is certainly slower than what we used to have.  The only problem I see
on the old version (sure, it is not very fast version) is that for
strstr ("abcd", "") it returned "abcd"+4 rather than "abcd" because
strchr in that case changed p to point to the last character and then
strncmp returned 0.

The question reported in PR109306 is whether memcmp is required not to
access characters beyond the first difference or not.
For all of memcmp/strcmp/strncmp, C17 says:
"The sign of a nonzero value returned by the comparison functions memcmp, strcmp, and strncmp
is determined by the sign of the difference between the values of the first pair of characters (both
interpreted as unsigned char) that differ in the objects being compared."
but then in memcmp description says:
"The memcmp function compares the first n characters of the object pointed to by s1 to the first n
characters of the object pointed to by s2."
rather than something similar to strncmp wording:
"The strncmp function compares not more than n characters (characters that follow a null character
are not compared) from the array pointed to by s1 to the array pointed to by
s2."
So, while for strncmp it seems clearly well defined when there is zero
terminator before reaching the n, for memcmp it is unclear if say
int
memcmp (const void *s1, const void *s2, size_t n)
{
  int ret = 0;
  size_t i;
  const unsigned char *p1 = (const unsigned char *) s1;
  const unsigned char *p2 = (const unsigned char *) s2;

  for (i = n; i; i--)
    if (p1[i - 1] != p2[i - 1])
      ret = p1[i - 1] < p2[i - 1] ? -1 : 1;
  return ret;
}
wouldn't be valid implementation (one which always compares all characters
and just returns non-zero from the first one that differs).

So, shouldn't we just revert and handle the len == 0 case correctly?

I think almost nothing really uses it, but still, the old version
at least worked nicer with a fast strchr.
Could as well strncmp (p + 1, s2 + 1, len - 1) if that is preferred
because strchr already compared the first character.

2023-04-02  Jakub Jelinek  <jakub@redhat.com>

	PR other/109306
	* strstr.c: Revert the 2020-11-13 changes.
	(strstr): Return s1 if len is 0.

Vector mac instructions has LRA issue during high register pressure,
It will failed to reload when picked first alternative, because it will
require reload 2 input operands into same register as input operand,
so we adding an extra operand to generate one more move pattern to
relax such restricted constraint.

This path fix ICE of ternary intrinsic:
bug.C:144:2: error: unable to find a register to spill
  144 |  }
      |  ^
bug.C:144:2: error: this is the insn:
(insn 462 972 919 24 (set (reg/v:VNx8DI 546 [orig:192 var_10 ] [192])
        (if_then_else:VNx8DI (unspec:VNx8BI [
                    (reg/v:VNx8BI 603 [orig:179 var_13 ] [179])
                    (const_int 13 [0xd])
                    (const_int 2 [0x2])
                    (const_int 0 [0]) repeated x2
                    (reg:SI 66 vl)
                    (reg:SI 67 vtype)
                ] UNSPEC_VPREDICATE)
            (plus:VNx8DI (mult:VNx8DI (reg/v:VNx8DI 605 [orig:190 var_6 ] [190])
                    (reg/v:VNx8DI 547 [orig:160 var_51 ] [160]))
                (reg/v:VNx8DI 548 [orig:161 var_52 ] [161]))
            (reg/v:VNx8DI 605 [orig:190 var_6 ] [190]))) "bug.C":131:48 4171 {*pred_maddvnx8di}
     (expr_list:REG_DEAD (reg/v:VNx8DI 605 [orig:190 var_6 ] [190])
        (expr_list:REG_DEAD (reg/v:VNx8BI 603 [orig:179 var_13 ] [179])
            (expr_list:REG_DEAD (reg/v:VNx8DI 547 [orig:160 var_51 ] [160])
                (expr_list:REG_DEAD (reg/v:VNx8DI 548 [orig:161 var_52 ] [161])
                    (nil))))))

gcc/ChangeLog:

	* config/riscv/vector.md: Fix RA constraint.

gcc/testsuite/ChangeLog:

	* g++.target/riscv/rvv/base/bug-19.C: New test.
	* g++.target/riscv/rvv/base/bug-20.C: New test.
	* g++.target/riscv/rvv/base/bug-21.C: New test.
	* g++.target/riscv/rvv/base/bug-22.C: New test.

Signed-off-by: Ju-Zhe Zhong <juzhe.zhong@rivai.ai>
Co-authored-by: kito-cheng <kito.cheng@sifive.com>

We need to reset the AVL to 0 or 1 for scalar move for RV32 system,
For any non-zero AVL input, we set that to 1, and zero will keep as zero.

We are using wrong way (by andi with 1) before to achieve that, and it
will cause ICE with const_int, and also wrong behavior, so now we have
two code path, one for const_int and one for non-const_int.

bug.C:144:2: error: unrecognizable insn:
  144 |  }
      |  ^
(insn 684 683 685 26 (set (reg:SI 513)
        (and:SI (const_int 4 [0x4])
            (const_int 1 [0x1]))) "bug.C":115:47 -1
     (nil))

andi a4,a4,1 ===> sgtu a4,a4,zero
vsetlvi tu        vsetvli tu
vlse              vlse

gcc/ChangeLog:

	* config/riscv/riscv-protos.h (gen_avl_for_scalar_move): New function.
	* config/riscv/riscv-v.cc (gen_avl_for_scalar_move): New function.
	* config/riscv/vector.md: Fix scalar move bug.

gcc/testsuite/ChangeLog:

	* gcc.target/riscv/rvv/base/scalar_move-6.c: Adapt test.
	* gcc.target/riscv/rvv/base/scalar_move-9.c: New test.