Fortran: reject module variable as character length in PARAMETER [PR104349]

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.

range-op-float: Fix reverse ops of comparisons [PR109386]

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.

sanitizer: missing signed integer overflow errors [PR109107]

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.

arm: Fix vcreate definition

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.

libstdc++: Fix outdated docs about demangling exception messages

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.

amdgcn: Add 64-bit vector not

gcc/ChangeLog:

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

riscv: Fix bootstrap [PR109384]

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.

config: -pthread shouldn't link with -lpthread on Solaris

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.

tree-optimization/109304 - properly handle instrumented aliases

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.

rs6000: Fix vector_set_var_p9 by considering BE [PR108807]

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.

rs6000: Fix vector parity support [PR108699]

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.

c++: friend template matching [PR107484]

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.

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

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>

Daily bump.

c++: ICE with loopy var tmpl auto deduction [PR109300]

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.

Update gcc sv.po

* sv.po: Update.

PR modula2/109388 clang warnings related to Modula-2

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>

ipa: Avoid constructing aggregate jump functions with huge offsets (PR 109303)

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.

build: Check that -lzstd can be linked

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.

param: document ranger-recompute-depth

gcc/ChangeLog:

* doc/invoke.texi: Document new param.

Added item entry in docs for the new check_effective_target.

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

RISC-V: Fix typo

gcc/ChangeLog:

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

rs6000: Modify test case after mode promotion disabled

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

Document signbitm2.

gcc/ChangeLog:

* doc/md.texi: Document signbitm2.

Daily bump.

Fix gnat.dg/opt39.adb on hppa.

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.

Skip gnat.dg/prot7.adb on hppa.

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.

PR modula2/109336 pass -fmod= though and build m2/stage2/cc1gm2 libs

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>

libiberty: Make strstr.c in libiberty ANSI compliant

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.

RISC-V: Fix reload fail issue on vector mac instructions

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>

RISC-V: Fix ICE and codegen error of scalar move in RV32 system.

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.

Daily bump.

c++: NTTP constraint depending on outer parms [PR109160]

Here we're crashing during satisfaction for the NTTP 'C<B> auto V'
ultimately because convert_template_argument / unify don't pass all
outer template arguments to do_auto_deduction, and during satisfaction
we need to know all arguments.  While these callers do pass some outer
arguments, they are only sufficient to properly substitute the
(level-lowered) 'auto' and are not necessarily the entire set.

Fortunately it seems these callers have access to the full set of outer
arguments via convert_template_argument's 'in_decl' parameter and
unify's 'tparms' parameter.  So this patch adds a new parameter to
do_auto_deduction, used only during adc_unify deduction, through which
these callers can pass the enclosing (partially instantiated) template
and from which do_auto_deduction can obtain _all_ outer template
arguments for sake of satisfaction.

This patch also ensures that the 'in_decl' argument passed to
coerce_template_parms is always a TEMPLATE_DECL, which in turn allows us
to pass it as-is to do_auto_deduction; the only coerce_template_parms
caller that needed adjustment was tsubst_decl it seems.

PR c++/109160

gcc/cp/ChangeLog:

* cp-tree.h (do_auto_deduction): Add defaulted tmpl parameter.
* pt.cc (convert_template_argument): Pass 'in_decl' as 'tmpl' to
do_auto_deduction.
(tsubst_decl) <case VAR_/TYPE_DECL>: Pass 'tmpl' instead of 't' as
'in_decl' to coerce_template_parms.
(unify) <case TEMPLATE_PARM_INDEX>: Pass TPARMS_PRIMARY_TEMPLATE
as 'tmpl' to do_auto_deduction.
(do_auto_deduction): Document default arguments.  Rename local
variable 'tmpl' to 'ctmpl'.  Use 'tmpl' to obtain a full set of
template arguments for satisfaction in the adc_unify case.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts-placeholder12.C: New test.

c++: improve "NTTP argument considered unused" fix [PR53164, PR105848]

r13-995-g733a792a2b2e16 worked around the problem of (pointer to)
function NTTP arguments not always getting marked as odr-used, by
redundantly calling mark_used on the substituted ADDR_EXPR callee of a
CALL_EXPR.  That is just a narrow workaround however, since it assumes
the function is later called, but the use as a template argument alone
should constitute an odr-use of the function (since template arguments
are an evaluated context, and we're really passing its address); we
shouldn't need to subsequently call or otherwise use the function NTTP
argument.

This patch fixes this in a more general way by walking the template
arguments of each specialization that's about to be instantiated and
redundantly calling mark_used on all entities used within.  As before,
the call to mark_used as it worst a no-op, but it compensates for the
situation where the specialization was first formed in a template context
in which mark_used is inhibited.

Another approach would be to call mark_used whenever we substitute a
TEMPLATE_PARM_INDEX, but that would result in many more redundant calls
to mark_used compared to this approach.  And as the second testcase
below illustrates, we also need to walk C++20 class NTTP arguments which
can be large and thus expensive to walk repeatedly.  The change to
invalid_tparm_referent_p is needed to avoid incorrectly rejecting class
NTTP arguments containing function pointers as in the testcase.

(The third testcase is unrelated to this fix, but it helped rule out an
earlier approach I was considering and it seems we don't have existing
test coverage for this situation.)

PR c++/53164
PR c++/105848

gcc/cp/ChangeLog:

* pt.cc (invalid_tparm_referent_p): Accept ADDR_EXPR of
FUNCTION_DECL.
(instantiate_class_template): Call mark_template_arguments_used.
(tsubst_copy_and_build) <case CALL_EXPR>: Revert r13-995 change.
(mark_template_arguments_used): Define.
(instantiate_body): Call mark_template_arguments_used.

gcc/testsuite/ChangeLog:

* g++.dg/template/fn-ptr3a.C: New test.
* g++.dg/template/fn-ptr3b.C: New test.
* g++.dg/template/fn-ptr4.C: New test.

Change "long_double" into "long double" for C prototypes from Fortran.

gcc/fortran/ChangeLog:

* dump-parse-tree.cc (get_c_type_name): Fix "long_long"
type name to be "long long".

range-op-float: Further foperator_{,not_}equal::fold_range fix

On Fri, Mar 31, 2023 at 12:45:10PM +0200, Jakub Jelinek via Gcc-patches wrote:
>    - there is a missing case (not handled in this patch) where both operands
>      are known to be zeros, but not singleton zeros

This patch adds those cases.

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

* range-op-float.cc (foperator_equal::fold_range): If at least
one of the op ranges is not singleton and neither is NaN and all
4 bounds are zero, return [1, 1].
(foperator_not_equal::fold_range): In the same case return [0, 0].

range-op-float: Further comparison fixes

On Fri, Mar 31, 2023 at 09:57:54AM +0200, Jakub Jelinek via Gcc-patches wrote:
> and so if maybe_isnan, they always return [0, 1].  Now, thinking about it,
> this is unnecessary pessimization, for the case where the ... block
> returns range_false (type) we actually could do it also if maybe_isnan (op1,
> op2), because if one or both operands are NAN, the comparison will be false,
> and if neither is NAN, the comparison will be also false.  Will fix
> incrementally today.

Here it is.
1) the foperator_{,not_}equal::fold_range cases
   - we have correctly first a case handling known_isnan on either operand,
     return there range_false (type) - EQ, resp. range_true (type) - NE
   - next we handle the singleton cases, maybe_isnan + singleton isn't
     singleton, so these are ok
   - there is a missing case (not handled in this patch) where both operands
     are known to be zeros, but not singleton zeros
   - there is some !maybe_isnan (op1, op2) handling which tries to prove
     when the operands are certainly not equal and results in
     range_false (type) - EQ, resp. range_true (type) - NE
   - otherwise range_true_and_false (type)
   Now, I think (and this patch implements it) that the !maybe_isnan (op1, op2)
   check is unnecessary.  If we prove that when ignoring maybe NANs, the
   ranges don't intersect and so the comparison is always false for EQ or
   always true for NE, if NANs can appear, it doesn't change anything on
   that either, for EQ if NAN appears, the result is false like what we
   proved for the finite ranges, for NE if NAN appears, the result is true
   like what we proved for the finite ranges
2) foperator_{lt,le,gt,ge}::fold_range cases
   - these have correctly known_isnan on either operand first and return
     there range_false (type)
   - then !maybe_isnan (op1, op2) condition guarded checks
   - finally range_true_and_false (type) - so do that for
     maybe_isnan (op1, op2)
   Here in the !maybe_isnan (op1, op2) guarded code we have some condition
   which results in range_true (type), another condition which results in
   range_false (type) and otherwise range_true_and_false (type).
   Now, the condition which results in range_false (type) can be IMHO done
   also for the maybe_isnan (op1, op2) cases, because it is [0, 0]
   if both operands are finite or [0, 0] if either operand is NAN.
3) finally, LTGT_EXPR wasn't handled at all.  LTGT_EXPR is the inverse
   comparision to UNEQ_EXPR, I believe both raise exceptions only if
   either operand is sNaN, UNEQ_EXPR is true if both operands are
   either equal or either of the operands is NAN, while LTGT_EXPR is
   true if the operands compare either smaller or larger and is false if
   either of the operands is NAN.

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

* range-op-float.cc (foperator_equal::fold_range): Perform the
non-singleton handling regardless of maybe_isnan (op1, op2).
(foperator_not_equal::fold_range): Likewise.
(foperator_lt::fold_range, foperator_le::fold_range,
foperator_gt::fold_range, foperator_ge::fold_range): Perform the
real_* comparison check which results in range_false (type)
even if maybe_isnan (op1, op2).  Simplify.
(foperator_ltgt): New class.
(fop_ltgt): New variable.
(floating_op_table::floating_op_table): Handle LTGT_EXPR using
fop_ltgt.

* gcc.dg/torture/inf-compare-1.c: Add dg-additional-options
-fno-tree-dominator-opts -fno-tree-vrp.
* gcc.dg/torture/inf-compare-1-float.c: Likewise.
* gcc.dg/torture/inf-compare-2.c: Likewise.
* gcc.dg/torture/inf-compare-2-float.c: Likewise.

testsuite: Add testcase for already fixed PR [PR109362]

This PR got fixed with r13-137.
Add a testcase to make sure it doesn't reappear.

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

PR tree-optimization/109362
* gcc.target/i386/pr109362.c: New test.

aarch64, builtins: Include PR registers in FUNCTION_ARG_REGNO_P etc. [PR109254]

The following testcase is miscompiled on aarch64-linux in the regname pass,
because while the function takes arguments in the p0 register,
FUNCTION_ARG_REGNO_P doesn't reflect that, so DF doesn't know the register is
used in register passing. It sees 2 chains with p1 register and wants to
replace the second one and as DF doesn't know p0 is live at the start of the
function, it will happily use p0 register even when it is used in subsequent
instructions.

The following patch fixes that.  FUNCTION_ARG_REGNO_P returns non-zero
for p0-p3 (unconditionally, seems for the floating/vector registers it
doesn't conditionalize them on TARGET_FLOAT either, but if you want,
I can conditionalize p0-p3 on TARGET_SVE), similarly
targetm.calls.function_value_regno_p returns true for p0-p3 registers
if TARGET_SVE (again for consistency, that function conditionalizes
the float/vector on TARGET_FLOAT).

Now, that change broke bootstrap in libobjc and some
__builtin_apply_args/__builtin_apply/__builtin_return tests.  The
aarch64_get_reg_raw_mode hook already documents that SVE scalable arg/return
passing is fundamentally incompatible with those builtins, but unlike
the floating/vector regs where it forces a fixed vector mode, I think
there is no fixed mode which could be used for p0-p3.  So, I have tweaked
the generic code so that it uses VOIDmode return from that hook to signal
that a register shouldn't be touched by
__builtin_apply_args/__builtin_apply/__builtin_return
despite being mentioned in FUNCTION_ARG_REGNO_P or
targetm.calls.function_value_regno_p.

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

PR target/109254
* builtins.cc (apply_args_size): If targetm.calls.get_raw_arg_mode
returns VOIDmode, handle it like if the register isn't used for
passing arguments at all.
(apply_result_size): If targetm.calls.get_raw_result_mode returns
VOIDmode, handle it like if the register isn't used for returning
results at all.
* target.def (get_raw_result_mode, get_raw_arg_mode): Document what it
means to return VOIDmode.
* doc/tm.texi: Regenerated.
* config/aarch64/aarch64.cc (aarch64_function_value_regno_p): Return
TARGET_SVE for P0_REGNUM.
(aarch64_function_arg_regno_p): Also return true for p0-p3.
(aarch64_get_reg_raw_mode): Return VOIDmode for PR_REGNUM_P regs.

gcc/testsuite/
2023-04-01  Jakub Jelinek  <jakub@redhat.com>
    Richard Sandiford  <richard.sandiford@arm.com>

PR target/109254
* gcc.target/aarch64/sve/pr109254.c: New test.

c++,coroutines: Stabilize names of promoted slot vars [PR101118].

When we need to 'promote' a value (i.e. store it in the coroutine frame) it
is given a frame entry name.  This was based on the DECL_UID for slot vars.
However, when LTO is used, the names from multiple TUs become visible at the
same time, and the DECL_UIDs usually differ between units.  This leads to a
"ODR mismatch" warning for the frame type.

The fix here is to use the current promoted temporaries count to produce
the name, this is stable between TUs and computed per coroutine.

Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>
PR c++/101118

gcc/cp/ChangeLog:

* coroutines.cc (flatten_await_stmt): Use the current count of
promoted temporaries to build a unique name for the frame entries.

Daily bump.

libstdc++: Teach optimizer that empty COW strings are empty [PR107087]

The compiler doesn't know about the invariant that the _S_empty_rep()
object is immutable and so _M_length and _M_refcount are always zero.
This means that we get warnings about writing possibly-non-zero length
strings into buffers that can't hold them. If we teach the compiler that
the empty rep is always zero length, it knows it can be copied into any
buffer.

For Stage 1 we might want to also consider adding this to capacity():

if (_S_empty_rep()._M_capacity != 0)
  __builtin_unreachable();

And this to _Rep::_M_is_leaked() and _Rep::_M_is_shared():

  if (_S_empty_rep()._M_refcount != 0)
    __builtin_unreachable();

libstdc++-v3/ChangeLog:

PR tree-optimization/107087
* include/bits/cow_string.h (basic_string::size()): Add
optimizer hint that _S_empty_rep()._M_length is always zero.
(basic_string::length()): Call size().

testsuite, analyzer: Fix up pipe-glibc.c testcase [PR107396]

The gcc.dg/analyzer/pipe-glibc.c test FAILs when using recent glibc headers
and succeeds with older headers.
The important change is that
https://sourceware.org/git/?p=glibc.git;a=commit;h=c1760eaf3b575ad174fd88b252fd16bd525fa818
in 2021 added __attribute__ ((__malloc__ (fclose, 1))) attribute to fdopen,
so in write_to_pipe there is an excess warning:
.../gcc/testsuite/gcc.dg/analyzer/pipe-glibc.c: In function 'write_to_pipe':
.../gcc/testsuite/gcc.dg/analyzer/pipe-glibc.c:28:3: warning: use of possibly-NULL 'stream' where non-null expected [CWE-690] [-Wanalyzer-possible-null-argument]
.../gcc/testsuite/gcc.dg/analyzer/pipe-glibc.c:27:12: note: (1) this call could return NULL
.../gcc/testsuite/gcc.dg/analyzer/pipe-glibc.c:28:3: note: (2) argument 4 ('stream') from (1) could be NULL where non-null expected
<built-in>: note: argument 4 of '__builtin_fwrite' must be non-null
Strangely, nothing is reported on the read_from_pipe function, seems
fwrite/fprintf/fputc etc. are builtins in GCC and we mark the FILE *
arguments as nonnull there on the builtin declarations, while fgetc/fread
etc. aren't builtins and glibc doesn't mark any of those using nonnull.
Shall we change that on the glibc side?

Anyway, because this differs based on glibc version and I think the
above warning is not the primary intention of the test, I think it is
best to tweak it so that this warning isn't reported.
Another option would be avoid using glibc headers and use our own
declarations, or make sure we add the malloc with fclose attribute ourselves
(but fdopen in the libc headers could be a macro, so not sure
__typeof (fdopen) fdopen __attribute__ ((__malloc__, __malloc__ (fclose, 1)));
would work).  Or use -Wno-analyzer-possible-null-arguments in
dg-additional-options?

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

PR analyzer/107396
* gcc.dg/analyzer/pipe-glibc.c (read_from_pie, write_to_pipe): Exit
if fdopen returns NULL.

Adjust testcases to not produce errors..

tree-optimization/109363
gcc/testsuite/
* g++.dg/warn/Wstringop-overflow-4.C: Always check bogus message.
* gcc.dg/tree-ssa/pr23109.c: Disable better recomputations.

LRA: Implement commutative operands exchange for combining secondary memory reload and original insn

The patch implements trying commutative operands exchange for
combining secondary memory reload and original insn.

        PR rtl-optimization/109052

gcc/ChangeLog:

* lra-constraints.cc: (combine_reload_insn): New function.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr109052-2.c: New.

libstdc++: Avoid -Wmaybe-uninitialized warning in std::stop_source [PR109339]

We pass a const-reference to *this before it's constructed, and GCC
assumes that all const-references are accessed. Add the access attribute
to say it's not accessed.

libstdc++-v3/ChangeLog:

PR libstdc++/109339
* include/std/stop_token (_Stop_state_ptr(const stop_source&)):
Add attribute access with access-mode 'none'.
* testsuite/30_threads/stop_token/stop_source/109339.cc: New test.

libstdc++: Revert addition of boolean flag to net::ip::basic_endpoint

As pointed out in P2641R1, we can use GCC's __builtin_constant_p to
emulate the proposed std::is_active_member. This allows us to detect
which of the union members is active during constant evaluation, so we
don't need the extra bool data member. We still can't support constexpr
until C++20 though, as we need to change the active member during
constant evaluation.

libstdc++-v3/ChangeLog:

* include/experimental/internet (ip::basic_endpoint::_M_if_v6):
Revert change from member function to data member. Fix for
constant evaluation by detecting which union member is active.
(ip::basic_endpoint::resize): Revert changes to update _M_is_v6
flag.

range-op-float, value-range: Fix up handling of UN{LT,LE,GT,GE,EQ}_EXPR and handle comparisons in get_tree_range [PR91645]

When looking into PR91645, I've noticed we handle UN{LT,LE,GT,GE,EQ}_EXPR
comparisons incorrectly.
All those are unordered or ..., we correctly return [1, 1] if one or
both operands are known NANs, and correctly ask the non-UN prefixed
op to fold_range if neither operand may be NAN.
But for the case where one or both operands may be NAN, we always
return [0, 1].  The UN* fold_range tries to handle it by asking
the non-UN prefixed fold_range and if it returns [1, 1] return that,
if it returns [0, 0] or [0, 1] return [0, 1], which makes sense,
because the maybe NAN means that it is the non-UN prefixed fold_range
unioned with [1, 1] in case the maybe NAN is actually NAN at runtime.
The problem is that the non-UN prefixed fold_range always returns [0, 1]
because those fold_range implementations are like:
  if (op1.known_isnan () || op2.known_isnan ())
    r = range_false (type);
  else if (!maybe_isnan (op1, op2))
    {
...
    }
  else
    r = range_true_and_false (type);
and so if maybe_isnan, they always return [0, 1].  Now, thinking about it,
this is unnecessary pessimization, for the case where the ... block
returns range_false (type) we actually could do it also if maybe_isnan (op1,
op2), because if one or both operands are NAN, the comparison will be false,
and if neither is NAN, the comparison will be also false.  Will fix
incrementally today.
Anyway, the following patch fixes it by asking the non-UN prefixed
fold_range on ranges with NAN cleared, which I think does the right
thing in all cases.

Another change in the patch is that range_query::get_tree_range
always returned VARYING for comparisons, this patch allows to ask about
those as well (they are very much like binary ops, except they take
the important type from the types of the operands rather than result).

Initially I've developed this patch together with changes to tree-call-cdce.cc,
but those result in one regression and apparently aren't actually needed to
fix this bug, the range-op-float.cc changes are enough.

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

PR tree-optimization/91645
* range-op-float.cc (foperator_unordered_lt::fold_range,
foperator_unordered_le::fold_range,
foperator_unordered_gt::fold_range,
foperator_unordered_ge::fold_range,
foperator_unordered_equal::fold_range): Call the ordered
fold_range on ranges with cleared NaNs.
* value-query.cc (range_query::get_tree_range): Handle also
COMPARISON_CLASS_P trees.

* gcc.target/i386/pr103559-1.c: New test.
* gcc.target/i386/pr103559-2.c: New test.
* gcc.target/i386/pr103559-3.c: New test.
* gcc.target/i386/pr103559-4.c: New test.

c++tools: Fix Makefile to properly clean and rebuild [PR101834]

The c++tools makefile doesn't remove progressively more files in each of
mostlyclean, clean, and distclean. Instead, each removes a different set
of files (and some files are not removed by any target). Use
prerequisites so that everything is removed.

Also, building in the $objdir/c++tools directory doesn't work, because
the INSTALL variable is never set. It works when building from the
top-level because INSTALL is set in the environment when recursively
invoking make for sub-directories.

c++tools/ChangeLog:

PR bootstrap/101834
* Makefile.in (INSTALL): Set variable.
(mostlyclean): Mark as a phony target.
(clean): Add mostlyclean as a prerequisite.
(distclean): Add clean as a prerequisite and remove more files.
(maintainer-clean): Add distclean as a prerequisite.

RISC-V: Fix missing file dependency in RISC-V back-end [PR109328]

gcc/ChangeLog:

PR target/109328
* config/riscv/t-riscv: Add missing dependencies.

Co-authored-by: Andrew Pinski <pinskia@gmail.com>

Adjust memory_move_cost for MASK_REGS when MODE_SIZE > 8.

It's impossible to put modes whose size > 8 into MASK_REGS.

gcc/ChangeLog:

* config/i386/i386.cc (inline_memory_move_cost): Return 100
for MASK_REGS when MODE_SIZE > 8.

c-c++-common/Warray-bounds.c: Fix excess warnings on LLP64

Excess errors on x86_64-w64-mingw32:
/home/user/p/gcc/src/gcc-git/gcc/testsuite/c-c++-common/Warray-bounds.c:50:3: warning: array subscript 4611686018427387902 is above array bounds of 'struct S16[]' [-Warray-bounds=]
/home/user/p/gcc/src/gcc-git/gcc/testsuite/c-c++-common/Warray-bounds.c:55:3: warning: array subscript 4611686018427387902 is above array bounds of 'struct S16[]' [-Warray-bounds=]
/home/user/p/gcc/src/gcc-git/gcc/testsuite/c-c++-common/Warray-bounds.c:90:3: warning: array subscript 658812288346769699 is above array bounds of 'struct S16[][7]' [-Warray-bounds=]

gcc/testsuite/ChangeLog:

* c-c++-common/Warray-bounds.c: Fix excess warnings on
LLP64.

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

Rename ufix_trunc/ufloat* patterns to fixuns_trunc/floatuns* to align with standard pattern name.

There's some typo for the standard pattern name for unsigned_{float,fix},
it should be floatunsmn2/fixuns_truncmn2, not ufloatmn2/ufix_truncmn2
in current trunk, the patch fix the typo, also change all though
ufix_trunc/ufloat patterns.

Also vcvttps2udq is available under AVX512VL, so it can be generated
directly instead of being emulated via vcvttps2dq.

gcc/ChangeLog:

PR target/85048
* config/i386/i386-builtin.def (BDESC): Adjust icode name from
ufloat/ufix to floatuns/fixuns.
* config/i386/i386-expand.cc
(ix86_expand_vector_convert_uns_vsivsf): Adjust comments.
* config/i386/sse.md
(ufloat<sseintvecmodelower><mode>2<mask_name><round_name>):
Renamed to ..
(<mask_codefor>floatuns<sseintvecmodelower><mode>2<mask_name><round_name>):.. this.
(<mask_codefor><avx512>_ufix_notrunc<sf2simodelower><mode><mask_name><round_name>):
Renamed to ..
(<mask_codefor><avx512>_fixuns_notrunc<sf2simodelower><mode><mask_name><round_name>):
.. this.
(<fixsuffix>fix_truncv16sfv16si2<mask_name><round_saeonly_name>):
Renamed to ..
(fix<fixunssuffix>_truncv16sfv16si2<mask_name><round_saeonly_name>):.. this.
(ufloat<si2dfmodelower><mode>2<mask_name>): Renamed to ..
(floatuns<si2dfmodelower><mode>2<mask_name>): .. this.
(ufloatv2siv2df2<mask_name>): Renamed to ..
(<mask_codefor>floatunsv2siv2df2<mask_name>): .. this.
(ufix_notrunc<mode><si2dfmodelower>2<mask_name><round_name>):
Renamed to ..
(fixuns_notrunc<mode><si2dfmodelower>2<mask_name><round_name>):
.. this.
(ufix_notruncv2dfv2si2): Renamed to ..
(fixuns_notruncv2dfv2si2):.. this.
(ufix_notruncv2dfv2si2_mask): Renamed to ..
(fixuns_notruncv2dfv2si2_mask): .. this.
(*ufix_notruncv2dfv2si2_mask_1): Renamed to ..
(*fixuns_notruncv2dfv2si2_mask_1): .. this.
(ufix_truncv2dfv2si2): Renamed to ..
(*fixuns_truncv2dfv2si2): .. this.
(ufix_truncv2dfv2si2_mask): Renamed to ..
(fixuns_truncv2dfv2si2_mask): .. this.
(*ufix_truncv2dfv2si2_mask_1): Renamed to ..
(*fixuns_truncv2dfv2si2_mask_1): .. this.
(ufix_truncv4dfv4si2<mask_name>): Renamed to ..
(fixuns_truncv4dfv4si2<mask_name>): .. this.
(ufix_notrunc<mode><sseintvecmodelower>2<mask_name><round_name>):
Renamed to ..
(fixuns_notrunc<mode><sseintvecmodelower>2<mask_name><round_name>):
.. this.
(ufix_trunc<mode><sseintvecmodelower>2<mask_name>): Renamed to ..
(<mask_codefor>fixuns_trunc<mode><sseintvecmodelower>2<mask_name>):
.. this.

gcc/testsuite/ChangeLog:

* g++.target/i386/pr85048.C: New test.

Daily bump.

c++: anonymous union member reference [PR105452]

While parsing the anonymous union, we don't yet know that it's an anonymous
union, so we build the reference to 'v' in the static_assert relative to the
union type.  But at instantiation time we know it's an anonymous union, so
we need to avoid trying to check access for 'v' in the union again; the
simplest approach seemed to be to make accessible_p step out to the
containing class.

While looking at this I also noticed that we were having trouble with DMI in
an anonymous union referring to members of the containing class; there
we just need to give current_class_ptr the right type.

PR c++/105452

gcc/cp/ChangeLog:

* search.cc (type_context_for_name_lookup): New.
(accessible_p): Handle anonymous union.
* init.cc (maybe_instantiate_nsdmi_init): Use
type_context_for_name_lookup.
* parser.cc (cp_parser_class_specifier): Likewise.
* cp-tree.h (type_context_for_name_lookup): Declare.

gcc/testsuite/ChangeLog:

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

c++: generic lambda and function ptr conv [PR105221]

We weren't properly considering the function pointer conversions in
deduction between FUNCTION_TYPE; we just hardcoded the
UNIFY_ALLOW_MORE_CV_QUAL semantics, which are backwards when deducing for a
template conversion function like the one in a generic lambda.  And when I
started checking the ALLOW flags, I needed to make sure they stay set to
avoid breaking trailing13.C.

PR c++/105221

gcc/cp/ChangeLog:

* pt.cc (unify) [FUNCTION_TYPE]: Handle function pointer
conversions.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1z/noexcept-type27.C: New test.

libiberty: Remove a reference to the Glibc manual

longjmp is not specific to Glibc, and GCC supports lots of systems
that do not use Glibc. Plus this link has been broken in the web
version for ages without a good way to fix.

libiberty/ChangeLog:

* obstacks.texi (Preparing for Obstacks): Remove a (broken)
reference to the Glibc manual.

c++: Fix up ICE in build_min_non_dep_op_overload [PR109319]

The following testcase ICEs, because grok_array_decl during
processing_template_decl handling of a non-dependent subscript
emits a -Wcomma-subscript pedwarn, we decide to pass to the
single index argument the index expressions as if it was wrapped
with () around it, but then when preparing it for later instantiation
we don't actually take that into account and ICE on a mismatch of
number of index arguments (the overload expects a single index,
testcase has two index expressions in this case).
For non-dependent subscript which are builtin subscripts we also
emit the same pedwarn and don't ICE, but emit the same pedwarn
again whenever we instantiate it, which is also IMHO undesirable,
it is enough to warn once during parsing the template.

The following patch fixes it by turning even the original index expressions
(those which didn't go through make_args_non_dependent) into a single
index using comma expression(s).

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

PR c++/109319
* decl2.cc (grok_array_decl): After emitting a pedwarn for
-Wcomma-subscript, if processing_template_decl set orig_index_exp
to compound expr from orig_index_exp_list.

* g++.dg/cpp23/subscript14.C: New test.

Add recursive GORI recompuations with a depth limit.

PR tree-optimization/109154
gcc/
* gimple-range-gori.cc (gori_compute::may_recompute_p): Add depth limit.
* gimple-range-gori.h (may_recompute_p): Add depth param.
* params.opt (ranger-recompute-depth): New param.

gcc/testsuite/
* gcc.dg/Walloca-13.c: Remove bogus warning that is now fixed.

c++: lambda mangling alias issues [PR107897]

In 107897, by the time we are looking at the mangling clash, the
alias has already been removed from the symbol table by analyze_functions,
so we can't look at n->cpp_implicit_alias.  So just assume that it's an
alias if it's internal.

In 108887 the problem is that removing the mangling alias from the symbol
table confuses analyze_functions, because it ended up as first_analyzed
somehow, so it becomes a dangling pointer.  So instead we call reset()
to neutralize the alias.  To make this work for variables, I needed to move
reset() from cgraph_node to symtab_node.

PR c++/107897
PR c++/108887

gcc/ChangeLog:

* cgraph.h: Move reset() from cgraph_node to symtab_node.
* cgraphunit.cc (symtab_node::reset): Adjust.  Also call
remove_from_same_comdat_group.

gcc/cp/ChangeLog:

* decl2.cc (record_mangling): Use symtab_node::reset.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts-lambda3.C: Use -flto if supported.
* g++.dg/cpp0x/lambda/lambda-mangle7.C: New test.

tree-optimization/107561 - reduce -Wstringop-overflow false positives

The following tells pointer-query to prefer a zero size when we
are querying for the size range for a write into an object we've
determined is of zero size.  That avoids diagnostics about really
varying size arguments that just get a meaningful range for example
because they are multiplied by an element size.

I've adjusted only one call to get_size_range since that's what
I have a testcase for.

PR tree-optimization/107561
* gimple-ssa-warn-access.cc (get_size_range): Add flags
argument and pass it on.
(check_access): When querying for the size range pass
SR_ALLOW_ZERO when the known destination size is zero.

* g++.dg/pr71488.C: Remove XFAILed bogus diagnostic again.
* g++.dg/warn/Warray-bounds-16.C: Likewise.

tree-optimization/109342 - wrong code with edge equivalences in VN

The following testcase shows a problem in how we query valitity for
equivalences on edges when the edge is a backedge and thus refering
to a block thats later in the iteration order we use for VN.  That
causes the dominated_by_p_w_unex helper to look at edge executable
state that's not yet computed and thus still at optimistic not
executable state.

The following makes sure to use a plain dominance check in these cases.

PR tree-optimization/109342
* tree-ssa-sccvn.cc (vn_nary_op_get_predicated_value): New
overload for edge.  When that edge is a backedge use
dominated_by_p directly.

* g++.dg/torture/pr109342.C: New testcase.

c++: Avoid informs without a warning [PR109278]

On the following testcase we emit notes in
maybe_inform_about_fndecl_for_bogus_argument_init
despite no warning/error being printed before it.
This is for the extended floating point type conversions where pedwarn
is used, and complained is used there for 2 different purposes,
one is whether an unspecific error should be emitted if we haven't
complained otherwise, and one whether
maybe_inform_about_fndecl_for_bogus_argument_init should be called.
For the 2 pedwarns, currently it sets complained to true regardless of
whether pedwarn succeeded, which results in the undesirable notes printed
with -w.  If complained is initialized to result of pedwarn, we would
emit an error later on.

So, the following patch makes complained a tristate, the additional
error isn't printed if complained != 0, and
maybe_inform_about_fndecl_for_bogus_argument_init is called only if
complained == 1, so if pedwarn returns false, we can use complained = -1
to tell later code not to emit an error and not to call
maybe_inform_about_fndecl_for_bogus_argument_init.

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

PR c++/109278
* call.cc (convert_like_internal): If pedwarn for extended float
type conversions doesn't report anything, avoid calling
maybe_inform_about_fndecl_for_bogus_argument_init.

* g++.dg/cpp23/ext-floating15.C: New test.

Fix fc-prototypes usage with C_INT64_T and non LP64 Targets.

The problem here is we were outputing long_long instead of
"long long". This was just an oversight and a missing check.

Committed as obvious after a bootstrap/test on x86_64-linux-gnu.

gcc/fortran/ChangeLog:

* dump-parse-tree.cc (get_c_type_name): Fix "long_long"
type name to be "long long". Add a comment on why adding
2 to the name too.

Generate vpblendd instead of vpblendw for V4SI under AVX2.

gcc/ChangeLog:

* config/i386/i386-expand.cc (expand_vec_perm_blend): Generate
vpblendd instead of vpblendw for V4SI under avx2.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr88828-0.c: Adjust testcase.

Daily bump.

libstdc++: Fix filename of new test [PR109242]

libstdc++-v3/ChangeLog:

PR libstdc++/109242
* testsuite/20_util/optional/monadic/pr109340.cc: Moved to...
* testsuite/20_util/optional/monadic/pr109242.cc: ...here.

libstdc++: Fix constexpr functions in <experimental/internet>

Change ip::basic_endpoint to work in constant expressions, but only for
C++20 and later (due to the use of a union, which cannot change active
member in constexpr evaluation until C++20).

During constant evaluation we cannot inspect the common initial sequence
of basic_endpoint's union members to check whether sin_family == AF_INET
or AF_INET6.  This means we need to store an additional boolean member
that remembers whether we have a v4 or v6 address. The address type can
change behind our backs if a user copies an address to the data()
pointer and then calls resize(n), so we need to inspect the sa_family_t
member in the union after a resize and update the boolean. POSIX only
guarantees that the sa_family_t member of each protocol-specific address
structure is at the same offset and of the same type, not that there is
a common initial sequence. The check in resize is done using memcmp, so
that we avoid accessing an inactive member of the union if the
sockaddr_in and sockaddr_in6 structures do not have a common initial
sequence that includes the sa_family_t member.

libstdc++-v3/ChangeLog:

* include/experimental/internet (ip::make_address): Implement
missing overload.
(ip::address_v4::broadcast()): Avoid undefined shift.
(ip::basic_endpoint): Fix member functions for constexpr.
(ip::basic_endpoint::_M_is_v6): Replace member function with
data member, adjust member functions using it.
(ip::basic_endpoint::resize): Update _M_is_v6 based on sockaddr
content.
* testsuite/experimental/net/internet/address/v4/cons.cc: Fix
constexpr checks to work in C++14.
* testsuite/experimental/net/internet/address/v4/creation.cc:
Likewise.
* testsuite/experimental/net/internet/endpoint/cons.cc:
Likewise.
* testsuite/experimental/net/internet/network/v4/cons.cc:
Likewise.
* testsuite/experimental/net/internet/network/v4/members.cc:
Likewise.
* testsuite/experimental/net/internet/endpoint/extensible.cc: New test.

libstdc++: Apply small fix from LWG 3843 to std::expected

LWG 3843 adds some type requirements to std::expected::value to ensure
that it can correctly copy the error value if it needs to throw an
exception. We don't need to do anything to enforce that, because it will
already be ill-formed if the type can't be copied. The issue also makes
a small drive-by fix to ensure that a const E& is copied from the
non-const value()& overload, which this change implements.

libstdc++-v3/ChangeLog:

* include/std/expected (expected::value() &): Use const lvalue
for unex member passed to bad_expected_access constructor, as
per LWG 3843.

libstdc++: Use std::remove_cv_t in std::optional::transform [PR109340]

We need to strip cv-qualifiers from the result of the callable passed to
std::optional::transform.

For std::expected::transform and std::expected::transform_error I
noticed we were stripping cv-qualifiers but were also incorrectly
stripping references.

libstdc++-v3/ChangeLog:

PR libstdc++/109340
* include/std/expected (expected::transform): Use
std::remove_cv_t instead of std::remove_cvref_t.
(expected::transform_error): Likewise.
(expected<cv void, E>::transform): Likewise.
(expected<cv void, E>::transform_error): Likewise.
* include/std/optional (transform): Use std::remove_cv_t.
* testsuite/20_util/optional/monadic/pr109340.cc: New test.

libstdc++: Enforce requirements on template argument of std::optional

The standard does not allow std::optional<T&>, std::optional<T[1]>,
std::optional<T()> etc. and although we do give errors, they come from
down inside the internals of std::optional. We could improve the static
assertions at the top of the class so that users get a more precise
diagnostic:

optional:721:21: error: static assertion failed
721 |       static_assert(is_object_v<_Tp> && !is_array_v<_Tp>);

libstdc++-v3/ChangeLog:

* include/std/optional (optional): Adjust static assertion to
reject arrays and functions as well as references.
* testsuite/20_util/optional/requirements_neg.cc: New test.

CRIS: Make rtx-cost 0 for many CONST_INT "quick" operands

Stepping through a gdb session inspecting costs that cause
gcc.dg/tree-ssa/slsr-13.c to fail, exposed that before this
patch, cris_rtx_costs told that a shift of 1 of a register
costs 5, while adding two registers costs 4.

Making the cost of a quick-immediate constant equal to using
a register (default 0) reflects actual performance and
size-cost better.  It also happens to make
gcc.dg/tree-ssa/slsr-13.c pass with what looks like better
code being generated, and improves coremark performance by
0.4%.

But, blindly doing this for *all* valid operands that fit
the "quick-immediate" addressing mode, trips interaction
with other factors*, with the end result mixed at best.  So,
do this only for MINUS and logical operations for the time
being, and only for modes that fit in one register.

*) Examples of "other factors":

- A bad default implementation of insn_cost or actually,
pattern_cost, that looks only at the set_src_cost and
furthermore sees such a cost of 0 as invalid.  (Compare to
the more sane set_rtx_cost.)  This naturally tripped up
combine and ifcvt, causing all sorts of changes, good and
bad.

- Having the same cost, to compare a register with 0 as with
-31..31, means a compare insn of an eliminable form no
longer looks preferable.

* config/cris/cris.cc (cris_rtx_costs) [CONST_INT]: Return 0
for many quick operands, for register-sized modes.

PR modula2/109336 - The -fmod= and -fdef= options do not work

The -fmod= and -fdef= options do not work.  After the linking
re-implementation and subsequent restructuring the -fmod= amd -fdef= are
now broken.  This patch adds -fmod= and -fdef= processing into gm2spec.cc.
It also reduces the complexity of extension handling within M2Search
by storing the preceeding "." in the extension.

gcc/m2/ChangeLog:

PR modula2/109336
PR modula2/109315
* gm2-compiler/M2FileName.mod (CalculateFileName): Simplified by
ensuring the extension contains the ".".
(CalculateStemName): Re-formatted.
(ExtractExtension): Re-formatted.
(ExtractModule): Re-formatted.
* gm2-compiler/M2Options.def (setdefextension): Add block comment.
(setmodextension): Add block comment.  Re-formatted.
* gm2-compiler/M2Options.mod (setdefextension): Add block comment.
(setmodextension): Add block comment.  Re-formatted.
* gm2-compiler/M2Search.mod (FindSourceDefFile): Use
DefaultDefExt.
(DefaultDefExt): New constant.
(DefaultModExt): New constant.
(FindSourceModFile): Use DefaultModExt.
* gm2-gcc/m2decl.cc (m2decl_DeclareKnownVariable): Correct
spelling.
* gm2spec.cc (M2SOURCE): New constant.
(LANGSPEC): New value.
(MATHLIB): New value.
(WITHLIBC): New value.
(SKIPOPT): New value.
(lang_specific_driver): Replace seen_module_extension bool with
module_extension char *.  Detect -fmod= and remember extension.
Use the extension to detect modula-2 source and mark it as such.

gcc/testsuite/ChangeLog:

PR modula2/109336
* gm2/link/nondefaultext/pass/hello.md: New test.
* gm2/link/nondefaultext/pass/liba.dm: New test.
* gm2/link/nondefaultext/pass/liba.md: New test.
* gm2/link/nondefaultext/pass/link-nondefaultext-pass.exp: New test.

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

RISC-V: Add Z*inx imcompatible check in gcc

Z*inx is conflict with float extensions, add incompatible check when
z*inx and f extension both enabled.

Since all float extension imply f extension and all z*inx extension
imply zfinx extension, so we just need to check f with zfinx extension
as the base case.

Co-Authored by: Kito Cheng <kito.cheng@gmail.com>

gcc/ChangeLog:

* common/config/riscv/riscv-common.cc (riscv_subset_list::parse):
New check.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/arch-19.c: New test.

configure: deprecate --enable-link-mutex option

PR bootstrap/109310

gcc/ChangeLog:

* configure.ac: Emit a warning for deprecated option
--enable-link-mutex.
* configure: Regenerate.

tree-optimization/109331 - make sure to clean up the CFG after forwprop

When forwprop discovers unreachable code or makes decisions based
on unreachable edges make sure to cleanup the CFG since otherwise
SSA form can become invalid.

PR tree-optimization/109331
* tree-ssa-forwprop.cc (pass_forwprop::execute): When we
discover a taken edge make sure to cleanup the CFG.

* gcc.dg/torture/pr109331.c: New testcase.

scan generic vector tests before lowering

The g++.dg/pr94920.C testcase looks for a specific number of
ABS_EXPRs but the vector example is prone to vector lowering so
the following instead of scanning the optimized dump scans the
forwprop1 dump which is before vector lowering and the point the
transforms should have happened.

* g++.dg/pr94920.C: Scan forwprop1 instead of optimized.

tree-optimization/109327 - forwprop stmt removal issue

There's interfering between the to_removed queue and other mechanisms
removing stmts, in this case remove_prop_source_from_use.  The following
makes the to_remove queue draining more permissive.

PR tree-optimization/109327
* tree-ssa-forwprop.cc (pass_forwprop::execute): Deal with
already removed stmts when draining to_remove.

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

ipa/106124 - ICE with -fkeep-inline-functions and OpenMP

The testcases in this bug reveal cases where an early generated
type is collected because it was unused but gets attempted to
be recreated later when a late DIE for a function (an OpenMP
reduction) is created.  That's unexpected and possibly the fault
of OpenMP but the following allows the re-creation of the context
type to succeed.

PR ipa/106124
* dwarf2out.cc (lookup_type_die): Reset TREE_ASM_WRITTEN
so we can re-create the DIE for the type if required.

* g++.dg/gomp/pr106124.C: New testcase.

tree-ssa-math-opts: Move PROP_gimple_opt_math from sincos pass to powcabs [PR109301]

The following testcase ICEs since the sincos and vect pass order has
been swapped.  It is not valid to replace vector sqrt (sqrt (x)) with
pow (x, 0.25) because build_real on vector type is invalid (could be
handled by using build_uniform_cst and adjusting type passed to
build_real) but more importantly because nothing checks if we can
actually do vector pow.
While we have pow_optab, apparently no target defines it, so it doesn't
seem to be worth bothering with for now and the patch just punts on
non-scalar sqrts.
I think the other simplifications next to it are fine, as they mostly
use CBRT which doesn't even have internal function (so is a builtin
only and therefore always scalar), or have already pow in the IL (which
doesn't have optab and shouldn't be thus vector either).
It is true that with <bits/math-vector.h> we do vectorize some calls to
pow or cbrt (but don't handle others strangely), but those aren't using
internal functions but simd clones and so match.pd doesn't know anything
about those (at least for now).

The following patch fixes it by mostly restoring the state before
r13-1763 where canonicalize_math_p () was true only until the end of the
pass which transformed pow or pow-like calls before vectorization (formerly
sincos pass, now it is powcabs pass).
powcabs is a pass in the spot sincos was happening before, so the
only change was defer the sin+cos simplification into cexpi to a later
new pass (except for the name moving with it) and none of the
canonicalize_math_p () guarded simplification in match.pd seem to rely
on those sin+cos -> cexpi simplifications and canonicalize_math_p is
the only user of this property.

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

PR tree-optimization/109301
* tree-ssa-math-opts.cc (pass_data_cse_sincos): Change
properties_provided from PROP_gimple_opt_math to 0.
(pass_data_expand_powcabs): Change properties_provided from 0 to
PROP_gimple_opt_math.

* gcc.dg/pr109301.c: New test.

tree-optimization/109154 - improve if-conversion for vectorization

With multi-argument PHIs and now doing VN on the if-converted blocks
the optimization of CSEing condition and negated condition doesn't
work well anymore.  The following restores this a little bit for
the case of a single inverted condition into a COND_EXPR where
we can instead swap the COND_EXPR arms.  The same optimization
is already done for the case of two-argument PHIs.

This avoids one comparison/mask for the testcase at hand.

PR tree-optimization/109154
* tree-if-conv.cc (gen_phi_arg_condition): Handle single
inverted condition specially by inverting at the caller.
(gen_phi_arg_condition): Swap COND_EXPR arms if requested.

c++: alias ctad refinements [PR109321]

The two hunks fix missing handling demonstrated by the two testcases: first,
if we omit one alias template parm but include another, we need to rewrite
the deduced template args to reflect the new position of the included parm.
Second, if we can't deduce any template args for a parameter pack, it is
deduced to an empty pack.

PR c++/109321
PR c++/109320

gcc/cp/ChangeLog:

* pt.cc (alias_ctad_tweaks): Rewrite deduced args.
(type_targs_deducible_from): Handle null pack deduction.

gcc/testsuite/ChangeLog:

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

compiler: mark Call_expression multiple results as a result struct

In https://go.dev/cl/343873 we stopped padding zero-sized trailing
fields in functions that return multiple results where the last result
is zero-sized. This CL makes the corresponding change on the caller side.

The test case is https://go.dev/cl/479898.

Fixes golang/go#55242

Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/479955

Daily bump.

Update gcc de.po

* de.po: Update.

libstdc++: Do not use facets cached in ios for ATL128 build [PR103387]

For the powerpc64le build with two different long double
representations, we cannot use the ios_base::_M_num_put and
ios_base::_M_num_get pointers, because they might have been initialized
in a translation unit using the other long double type. With the changes
to add __try_use_facet to GCC 13 the cache isn't really needed now, we
can just access the right facet in the locale directly, without needing
RTTI checks.

libstdc++-v3/ChangeLog:

PR libstdc++/103387
* include/bits/istream.tcc (istream::_M_extract(ValueT&)): Use
std::use_facet instead of cached _M_num_get facet.
(istream::operator>>(short&)): Likewise.
(istream::operator>>(int&)): Likewise.
* include/bits/ostream.tcc (ostream::_M_insert(ValueT)): Use
std::use_facet instead of cached _M_num_put facet.

Enable 'gfortran.dg/weak-2.f90' for nvptx target

Follow-up to commit bcbeebc498126c50d73809ec8a4bd0bff27ee97b
"Fortran: Add support for WEAK attribute for variables".

gcc/testsuite/
* gfortran.dg/weak-2.f90: Enable for nvptx target.

libstdc++: More fixes for null pointers used with std::char_traits

The std::char_traits member functions require that [p,p+n) is a valid
range, which is true for p==nullptr iff n==0. But we must not call
memcpy, memset etc, in that case, as they require non-null pointers even
when n==0.

This std::char_traits<char> and std::char_traits<wchar_t> explicit
specializations are already correct, but the primary template has some
bugs.

libstdc++-v3/ChangeLog:

* include/bits/char_traits.h (char_traits::copy): Return without
using memcpy if n==0.
(char_traits::assign): Likewise for memset.

libstdc++: Tell GCC what basic_string::_M_is_local() means [PR109299]

This avoids a bogus warning about overflowing a buffer, because GCC
can't tell that we don't copy into the buffer unless it fits. By adding
a __builtin_unreachable() hint we inform the compiler about the
invariant that the buffer is only used when it's big enough.

This can also improve codegen, by eliminating dead code that GCC
couldn't tell was unreachable.

libstdc++-v3/ChangeLog:

PR libstdc++/109299
* include/bits/basic_string.h (basic_string::_M_is_local()): Add
hint for compiler that local strings fit in the local buffer.

libstdc++: Update tzdata to 2023a [PR109288]

Import the new 2023a tzdata.zi file and update the expiry dates of the
hardcoded lists of leapseconds to 2023-12-28.

With the new data, Africa/Egypt no longer has a single unbroken sys_info
from 2014-09-25 to chrono::year::max(). Only check up to 2014-09-01 so
that the test isn't sensitive to differences between 2022g and 2023a
data.

libstdc++-v3/ChangeLog:

PR libstdc++/109288
* include/std/chrono (__detail::__get_leap_second_info): Update
expiry date of hardcoded leapseconds list.
* src/c++20/tzdb.cc (tzdb_list::_Node::_S_read_leap_seconds()):
Likewise.
* src/c++20/tzdata.zi: Import new file from 2023a release.
* testsuite/std/time/time_zone/get_info_local.cc: Only check
transitions for Egypt up to 2014.

libbacktrace: minor fixes for zstd decompression

* elf.c (elf_zstd_read_fse): Call elf_fetch_bits after reading
bits, not before.  Add unlikely for error case.
(elf_zstd_offset_table): Regenerate.
(elf_zstd_read_huff): Clear 13 entries in weight_mark, not 12.
(elf_zstd_read_literals): For a single stream adjust by
total_streams_size, not compressed_size.

Don't emit -Wxor-used-as-pow on macro expansions [PR107002]

PR c/107002 reports an assertion failure from deep inside the
diagnostic_shows_locus when attempting to print fix-it hints relating
to -Wxor-used-as-pow.  The case involves macro expansions with
-ftrack-macro-expansion=0.

It doesn't seem to make much sense to emit this warning for macro
expansions, so this patch updates the warning not to (which seems
to also be clang's behavior).  The patch also adds some bulletproofing
to diagnostic-show-locus.cc to be more robust against such invalid
fix-it hints.

Doing so fixes the ICE.

gcc/c-family/ChangeLog:
PR c/107002
* c-common.h (check_for_xor_used_as_pow): Add "rhs_loc" param.
* c-warn.cc (check_for_xor_used_as_pow): Add "rhs_loc" param.
Reject cases where involving macro expansions.

gcc/c/ChangeLog:
PR c/107002
* c-typeck.cc (parser_build_binary_op): Update for new param of
check_for_xor_used_as_pow.

gcc/cp/ChangeLog:
PR c/107002
* parser.cc (cp_parser_binary_expression): Update for new param of
check_for_xor_used_as_pow.

gcc/ChangeLog:
PR c/107002
* diagnostic-show-locus.cc (column_range::column_range): Factor
out assertion conditional into...
(column_range::valid_p): ...this new function.
(line_corrections::add_hint): Don't attempt to consolidate hints
if it would lead to invalid column_range instances.

gcc/testsuite/ChangeLog:
PR c/107002
* c-c++-common/Wxor-used-as-pow-1.c: Add macro test.
* c-c++-common/Wxor-used-as-pow-pr107002-0.c: New test.
* c-c++-common/Wxor-used-as-pow-pr107002-1.c: New test.
* c-c++-common/Wxor-used-as-pow-pr107002-2.c: New test.

Signed-off-by: David Malcolm <dmalcolm@redhat.com>

c++: Allow translations of check_postcondition_result messages [PR109309]

As mentioned in the PR, constructing a message from two parts by
concatenating them prevents translations, unless one of the parts
is a keyword which should be never translated.

The following patch fixes that.

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

PR c++/109309
* contracts.cc: Include intl.h.
(check_postcondition_result): Don't form diagnostics from two halves
of an English message to allow translations.

c-family: -Wsequence-point and COMPONENT_REF [PR107163]

The patch for PR91415 fixed -Wsequence-point to treat shifts and ARRAY_REF
as sequenced in C++17, and COMPONENT_REF as well.  But this is unnecessary
for COMPONENT_REF, since the RHS is just a FIELD_DECL with no actual
evaluation, and in this testcase handling COMPONENT_REF as sequenced blows
up fast in a deep inheritance tree.  Instead, look through it.

PR c++/107163

gcc/c-family/ChangeLog:

* c-common.cc (verify_tree): Don't use sequenced handling
for COMPONENT_REF.

gcc/testsuite/ChangeLog:

* g++.dg/warn/Wsequence-point-5.C: New test.

RISC-V: Define __riscv_v_intrinsic [PR109312]

RVV intrinsic has defined a macro to identity the version of RVV
intrinsic spec, we missed that before, thanksful we are catch this
before release.

gcc/ChangeLog:

PR target/109312
* config/riscv/riscv-c.cc (riscv_ext_version_value): New.
(riscv_cpu_cpp_builtins): Define __riscv_v_intrinsic and
minor refactor.

gcc/testsuite/ChangeLog:

PR target/109312
* gcc.target/riscv/predef-__riscv_v_intrinsic.c: New test.

libstdc++: Add missing trait is_simd_flag_type

Signed-off-by: Matthias Kretz <m.kretz@gsi.de>
libstdc++-v3/ChangeLog:

* include/experimental/bits/simd.h (is_simd_flag_type): New.
(_IsSimdFlagType): New.
(copy_from, copy_to, load ctors): Constrain _Flags using
_IsSimdFlagType.

haifa-sched: fix autopref_rank_for_schedule comparator [PR109187]

Do not attempt to use a plain subtraction for generating a three-way
comparison result in autopref_rank_for_schedule qsort comparator, as
offsets are not restricted and subtraction may overflow.  Open-code
a safe three-way comparison instead.

gcc/ChangeLog:

PR rtl-optimization/109187
* haifa-sched.cc (autopref_rank_for_schedule): Avoid use of overflowing
subtraction in three-way comparison.

gcc/testsuite/ChangeLog:

PR rtl-optimization/109187
* gcc.dg/pr109187.c: New test.

Fix compute_operand when op1 == op2 symbolically.

First, class value_relation should not sanitize records. just create
what is asked.

Second., if there is not a relation record, compute_operand was
creating one for op1 == op2 if op1 and op2 were the same symbol.   This
is not the correct way to communicate the information, as that record
will continue to be passed along the GORI unwind chain.

Instead, simply pass that information locally to the opX_range routine
for only the current statement.

PR tree-optimization/109265
PR tree-optimization/109274
gcc/
* gimple-range-gori.cc (gori_compute::compute_operand_range): Do
not create a relation record is op1 and op2 are the same symbol.
(gori_compute::compute_operand1_range): Pass op1 == op2 to the
handler for this stmt, but create a new record only if this statement
generates a relation based on the ranges.
(gori_compute::compute_operand2_range): Ditto.
* value-relation.h (value_relation::set_relation): Always create the
record that is requested.

gcc/testsuite/
* gcc.dg/pr109274.c: New.
* gfortran.dg/pr109265.f90: New.

tree-optimization/107087 - missed CCP after forwprop

When forwprop simplifies the CFG the 2nd order opportunities by
exposed degenerate PHIs are not realized.  The following improves
this by properly tracking executable edges and thus handling this
for non-cyclic CFGs at least.

This avoids the bogus diagnostic reported for the testcase in this PR.

PR tree-optimization/107087
* tree-ssa-forwprop.cc (pass_forwprop::execute): Track
executable regions to avoid useless work and to better
propagate degenerate PHIs.

* g++.dg/pr107087.C: New testcase.

mingw: Fix comments in x-mingw32-utf8

This is a comment-only change that I should have
done with the previous commit (304c7d44a) but
forgot to do so.

gcc/ChangeLog:

* config/i386/x-mingw32-utf8: update comments.

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