libstdc++: Add suggestion to std::uncaught_exception() warning

We should use the SUGGEST macro for std::uncaught_exception()
deprecation warnings.

libstdc++-v3/ChangeLog:

* include/bits/allocator.h: Qualify std::allocator_traits in
deprecated warnings.
* libsupc++/exception (uncaught_exception): Add suggestion to
deprecated warning.

testsuite: -mbig/-mlittle only is valid for powerpc-linux.

A recent change to some powerpc tests added explicit -mbig and -mlittle
options, but those options are not valid outside of powerpc-linux.

This patch updates the testcase options to enable -mbig when valid
and to only use -mlittle for powerpc-linux.

gcc/testsuite/ChangeLog:

* gcc.target/powerpc/builtins-1.c: Limit -mbig.
* gcc.target/powerpc/vsu/vec-cntlz-lsbb-0.c: Limit -mbig.
* gcc.target/powerpc/vsu/vec-cntlz-lsbb-1.c: Limit -mbig.
* gcc.target/powerpc/vsu/vec-cntlz-lsbb-2.c: Remove target selector.
* gcc.target/powerpc/vsu/vec-cntlz-lsbb-3.c: Only powerpc*-linux.
* gcc.target/powerpc/vsu/vec-cntlz-lsbb-4.c: Only powerpc*-linux*.
* gcc.target/powerpc/vsu/vec-cnttz-lsbb-0.c: Limit -mbig.
* gcc.target/powerpc/vsu/vec-cnttz-lsbb-1.c: Limit -mbig.
* gcc.target/powerpc/vsu/vec-cnttz-lsbb-2.c: Remove target selector.
* gcc.target/powerpc/vsu/vec-cnttz-lsbb-3.c: Only powerpc*-linux*.
* gcc.target/powerpc/vsu/vec-cnttz-lsbb-4.c: Only powerpc*-linux*.

libgomp.fortran/allocate-1.f90: Minor cleanup

libgomp/ChangeLog:
* testsuite/libgomp.fortran/allocate-1.c (is_64bit_aligned): Renamed
from is_64bit_aligned_.
* testsuite/libgomp.fortran/allocate-1.f90: Fix interface decl
and use it, more implicit none, remove unused argument.

tree-optimization/100499 - niter analysis and multiple_of_p

niter analysis uses multiple_of_p which currently assumes
operations like MULT_EXPR do not wrap.  We've got to rely on this
for optimizing size expressions like those in DECL_SIZE and those
generally use unsigned arithmetic with no indication that they
are not expected to wrap.  To preserve that the following adds
a parameter to multiple_of_p, defaulted to true, indicating that
the TOP expression is not expected to wrap for outer computations
in TYPE.  This mostly follows a patch proposed by Bin last year
with the conversion behavior added.

Applying to all users the new effect is that upon type conversions
in the TOP expression the behavior will switch to honor
TYPE_OVERFLOW_UNDEFINED for the converted sub-expressions.

The patch also changes the occurance in niter analysis that we
know is problematic and we have testcases for to pass false
to multiple_of_p.  The patch also contains a change to the
PR72817 fix from Bin to avoid regressing gcc.dg/tree-ssa/loop-42.c.

The intent for stage1 is to introduce a size_multiple_of_p and
internalize the added parameter so all multiple_of_p users will
honor TYPE_OVERFLOW_UNDEFINED and users dealing with size expressions
need to be switched to size_multiple_of_p.

2022-01-26  Richard Biener  <rguenther@suse.de>

PR tree-optimization/100499
* fold-const.h (multiple_of_p): Add nowrap parameter, defaulted
to true.
* fold-const.cc (multiple_of_p): Likewise.  Honor it for
MULT_EXPR, PLUS_EXPR and MINUS_EXPR and pass it along,
switching to false for conversions.
* tree-ssa-loop-niter.cc (number_of_iterations_ne): Do not
claim the outermost expression does not wrap when calling
multiple_of_p.  Refactor the check done to check the
original IV, avoiding a bias that might wrap.

* gcc.dg/torture/pr100499-1.c: New testcase.
* gcc.dg/torture/pr100499-2.c: Likewise.
* gcc.dg/torture/pr100499-3.c: Likewise.

Co-authored-by: Bin Cheng <bin.cheng@linux.alibaba.com>

fixincludes: Update pwd.

fixincludes/ChangeLog:

* fixinc.in: Use cd OLDDIR instead of cd .. .

Adjust LSHIFT_EXPR handling of multiple_of_p

This removes the odd check of size_type_node when handling left-shifts
as multiplications of 1 << N and instead uses the type as specified.
It also moves left-shift handling next to multiplications where it
semantically belongs.

2022-01-24  Richard Biener  <rguenther@suse.de>

* fold-const.cc (multiple_of_p): Re-write and move LSHIFT_EXPR
handling.

Empty the base_types vector before (re)populating it

Otherwise Bad Things happen when it is populated several times.

gcc/
PR debug/104366
* dwarf2out.cc (dwarf2out_finish): Empty base_types.
(dwarf2out_early_finish): Likewise.

Disable new 1/X optimization with -fnon-call-exceptions

The trapping behavior of the operation needs to be preserved when the
-fnon-call-exceptions switch is in effect.  This also adds the same
guards to similar optimizations.

gcc/
PR tree-optimization/104356
* match.pd (X / bool_range_Y is X): Add guard.
(X / X is one): Likewise.
(X / abs (X) is X < 0 ? -1 : 1): Likewise.
(X / -X is -1): Likewise.
(1 / X -> X == 1): Likewise.

tree-optimization/103641 - improve vect_synth_mult_by_constant

The following happens to improve compile-time of the PR103641
testcase on aarch64 significantly.  I did not investigate the
effect on the generated code but at least in theory
choose_mult_variant should do a better job when we tell it
the actual mode we are going to use for the operations it
synthesizes.

2022-02-04  Richard Biener  <rguenther@suse.de>

PR tree-optimization/103641
* tree-vect-patterns.cc (vect_synth_mult_by_constant):
Pass the vector mode to choose_mult_variant.

[PATCH] PR rtl-optimization/101885: Prevent combine from clobbering flags

This patch addresses PR rtl-optimization/101885 which is a P2 wrong code
regression.  In combine, if the resulting fused instruction is a parallel
of two sets which fails to be recognized by the backend, combine tries to
emit these as two sequential set instructions (known as split_i2i3).
As each set is recognized the backend may add any necessary "clobbers".
The code currently checks that any clobbers added to the first "set"
don't interfere with the second set, but doesn't currently handle the
case that clobbers added to the second set may interfere/kill the
destination of the first set (which must be live at this point).
The solution is to cut'n'paste the "clobber" logic from just a few
lines earlier, suitably adjusted for the second instruction.

One minor nit that may confuse a reviewer is that at this point in
the code we've lost track of which set was first and which was second
(combine chooses dynamically, and the recog processes that adds the
clobbers may have obfuscated the original SET_DEST) so the actual test
below is to confirm that any newly added clobbers (on the second set
instruction) don't overlap either set0's or set1's destination.

2022-02-04  Roger Sayle  <roger@nextmovesoftware.com>

gcc/ChangeLog
PR rtl-optimization/101885
* combine.cc (try_combine): When splitting a parallel into two
sequential sets, check not only that the first doesn't clobber
the second but also that the second doesn't clobber the first.

gcc/testsuite/ChangeLog
PR rtl-optimization/101885
* gcc.dg/pr101885.c: New test case.

aarch64: Add test for PR104092

gcc/testsuite/
PR middle-end/104092
* gcc.target/aarch64/sve/acle/general/pr104092.c: New test.

Add CLOBBER_EOL to mark storage end-of-life clobbers

This adds a flag to CONSTRUCTOR nodes indicating that for
clobbers this marks the end-of-life of storage as opposed to
just ending the lifetime of the object that occupied it.
The dangling pointer diagnostics uses CLOBBERs but is confused
by those emitted by the C++ frontend for example which emits
them for the second purpose at the start of CTORs.  The issue
is also appearant for aarch64 in PR104092.

Distinguishing the two cases is also necessary for the PR90348 fix.

Since I'm going to add another flag I added an enum clobber_flags
and a defaulted argument to build_clobber plus a convenient way to
query the enum from the CTOR tree and specify it for gimple_clobber_p.
Since 'CLOBBER' is already taken and I needed a name for the unspecified
clobber we have now I used 'CLOBBER_UNDEF'.

2022-02-03  Richard Biener  <rguenther@suse.de>

PR middle-end/90348
PR middle-end/104092
gcc/
* tree-core.h (clobber_kind): New enum.
(tree_base::u::bits::address_space): Document use in CONSTRUCTORs.
* tree.h (CLOBBER_KIND): Add.
(build_clobber): Add clobber kind argument, defaulted to
CLOBBER_UNDEF.
* tree.cc (build_clobber): Likewise.
* gimple.h (gimple_clobber_p): New overload with specified kind.
* tree-streamer-in.cc (streamer_read_tree_bitfields): Stream
CLOBBER_KIND.
* tree-streamer-out.cc (streamer_write_tree_bitfields):
Likewise.
* tree-pretty-print.cc (dump_generic_node): Mark EOL CLOBBERs.
* gimplify.cc (gimplify_bind_expr): Build storage end-of-life clobbers
with CLOBBER_EOL.
(gimplify_target_expr): Likewise.
* tree-inline.cc (expand_call_inline): Likewise.
* tree-ssa-ccp.cc (insert_clobber_before_stack_restore): Likewise.
* gimple-ssa-warn-access.cc (pass_waccess::check_stmt): Only treat
CLOBBER_EOL clobbers as ending lifetime of storage.

gcc/lto/
* lto-common.cc (compare_tree_sccs_1): Compare CLOBBER_KIND.

gcc/testsuite/
* gcc.dg/pr87052.c: Adjust.

Use auto_vec for pointer_query cache for auto cleanup.

gcc/Changelog:

* pointer-query.h (pointer_query::cache_type): Use auto_vec for auto
cleanup.

Daily bump.

c++: dependence of member noexcept-spec [PR104079]

Here a stale TYPE_DEPENDENT_P/_P_VALID value for f's function type
after replacing the type's DEFERRED_NOEXCEPT with the parsed dependent
noexcept-spec causes us to try to instantiate g's noexcept-spec ahead
of time (since it in turn appears non-dependent), leading to an ICE.

This patch fixes this by clearing TYPE_DEPENDENT_P_VALID in
fixup_deferred_exception_variants appropriately (as in
build_cp_fntype_variant).

That turns out to fix the testcase for C++17 but not for C++11/14,
because it's not until C++17 that a noexcept-spec is part of (and
therefore affects dependence of) the function type.  Since dependence of
NOEXCEPT_EXPR is defined in terms of instantiation dependence, the most
appropriate fix for earlier dialects seems to be to make instantiation
dependence consider dependence of a noexcept-spec.

PR c++/104079

gcc/cp/ChangeLog:

* pt.cc (value_dependent_noexcept_spec_p): New predicate split
out from ...
(dependent_type_p_r): ... here.
(instantiation_dependent_r): Use value_dependent_noexcept_spec_p
to consider dependence of a noexcept-spec before C++17.
* tree.cc (fixup_deferred_exception_variants): Clear
TYPE_DEPENDENT_P_VALID.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/noexcept74.C: New test.
* g++.dg/cpp0x/noexcept74a.C: New test.

analyzer: fixes to realloc-handling [PR104369]

This patch fixes various issues with how -fanalyzer handles "realloc"
seen when debugging PR analyzer/104369.

Previously it wasn't correctly copying over the contents of the old
buffer for the success-with-move case, leading to false
-Wanalyzer-use-of-uninitialized-value diagnostics.

I also noticed that -fanalyzer failed to properly handle "realloc" for
cases where the ptr's region had unknown dynamic extents, and an ICE
for the case where a tainted value is used as a realloc size argument.

This patch fixes these issues, including the false uninit diagnostics
seen in PR analyzer/104369.

gcc/analyzer/ChangeLog:
PR analyzer/104369
* engine.cc (exploded_graph::process_node): Use the node for any
diagnostics, avoiding ICE if a bifurcation update adds a
saved_diagnostic, such as for a tainted realloc size.
* region-model-impl-calls.cc
(region_model::impl_call_realloc::success_no_move::update_model):
Require the old pointer to be non-NULL to be able successfully
grow in place.  Use model->deref_rvalue rather than maybe_get_region
to support the old pointer being symbolic.
(region_model::impl_call_realloc::success_with_move::update_model):
Likewise.  Add a constraint that the new pointer != the old pointer.
Use a sized_region when setting the value of the new region.
Handle the case where we don't know the dynamic size of the old
region by marking the new region as unknown.
* sm-taint.cc (tainted_allocation_size::tainted_allocation_size):
Update assertion to also allow for MEMSPACE_UNKNOWN.
(tainted_allocation_size::emit): Likewise.
(region_model::check_dynamic_size_for_taint): Likewise.

gcc/testsuite/ChangeLog:
PR analyzer/104369
* gcc.dg/analyzer/pr104369-1.c: New test.
* gcc.dg/analyzer/pr104369-2.c: New test.
* gcc.dg/analyzer/realloc-3.c: New test.
* gcc.dg/analyzer/realloc-4.c: New test.
* gcc.dg/analyzer/taint-realloc.c: New test.

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

analyzer: fix zero-fill of calloc

It turned out that the analyzer wasn't treating calloc regions
as zero-filled, due to binding_cluster::fill_region getting an
unknown value for the byte_size_size_sval, and thus
get_or_create_repeated_svalue returning an unknown_svalue, which
was then used to fill the region.

Fixed thusly.

gcc/analyzer/ChangeLog:
* region-model-impl-calls.cc (region_model::impl_call_calloc): Use
a sized_region when calling zero_fill_region.

gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/calloc-1.c: New test.

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

Adjust warn_access pass placement [PR104260].

Resolves:
PR middle-end/104260 - Misplaced waccess3 pass

gcc/ChangeLog:

PR middle-end/104260
* passes.def (pass_warn_access): Adjust pass placement.

i386: Do not use %ecx DRAP for functions that use __builtin_eh_return [PR104362]

%ecx can't be used for both DRAP register and eh_return.  Adjust find_drap_reg
to choose %edi for functions that uses __builtin_eh_return to avoid the assert
in ix86_expand_epilogue that enforces this rule.

2022-02-03  Uroš Bizjak  <ubizjak@gmail.com>

gcc/ChangeLog:

PR target/104362
* config/i386/i386.cc (find_drap_reg): For 32bit targets
return DI_REG if function uses __builtin_eh_return.

gcc/testsuite/ChangeLog:

PR target/104362
* gcc.target/i386/pr104362.c: New test.

Enable pointer_query caching in -Wrestrict.

gcc/ChangeLog:

* gimple-ssa-warn-restrict.cc (class pass_wrestrict): Outline ctor.
(pass_wrestrict::m_ptr_qry): New member.
(wrestrict_walk): Rename...
(pass_wrestrict::check_block): ...to this.
(pass_wrestrict::execute): Set up and tear down pointer_query and
ranger.
(builtin_memref::builtin_memref): Change ctor argument.  Simplify.
(builtin_access::builtin_access): Same.
(builtin_access::m_ptr_qry): New member.
(check_call): Rename...
(pass_wrestrict::check_call): ...to this.
(check_bounds_or_overlap): Change argument.
* gimple-ssa-warn-restrict.h (check_bounds_or_overlap): Same.

Enable pointer_query caching in -Warray-bounds.

gcc/ChangeLog:

* gimple-array-bounds.cc (array_bounds_checker::array_bounds_checker):
Define ctor.
(array_bounds_checker::get_value_range): Use new member.
(array_bounds_checker::check_mem_ref): Same.
* gimple-array-bounds.h (array_bounds_checker::array_bounds_checker):
Outline ctor.
(array_bounds_checker::m_ptr_query): New member.

Make pointer_query cache a private member.

gcc/ChangeLog:

* gimple-ssa-warn-access.cc (pass_waccess::pass_waccess): Remove
pointer_query cache.
* pointer-query.cc (pointer_query::pointer_query): Remove cache
argument.  Zero-initialize new cache member.
(pointer_query::get_ref): Replace cache pointer with direct access.
(pointer_query::put_ref): Same.
(pointer_query::flush_cache): Same.
(pointer_query::dump): Same.
* pointer-query.h (class pointer_query): Remove cache argument from
ctor.  Change cache pointer to cache subobject member.
* tree-ssa-strlen.cc: Remove pointer_query cache.

Constrain conservative string lengths to array sizes [PR104119].

Resolves:
PR tree-optimization/104119 - unexpected -Wformat-overflow after strlen in ILP32 since Ranger integration

gcc/ChangeLog:

PR tree-optimization/104119
* gimple-ssa-sprintf.cc (struct directive): Change argument type.
(format_none): Same.
(format_percent): Same.
(format_integer): Same.
(format_floating): Same.
(get_string_length): Same.
(format_character): Same.
(format_string): Same.
(format_plain): Same.
(format_directive): Same.
(compute_format_length): Same.
(handle_printf_call): Same.
* tree-ssa-strlen.cc (get_range_strlen_dynamic): Same.   Call
get_maxbound.
(get_range_strlen_phi): Same.
(get_maxbound): New function.
(strlen_pass::get_len_or_size): Adjust to parameter change.
* tree-ssa-strlen.h (get_range_strlen_dynamic): Change argument type.

gcc/testsuite/ChangeLog:

PR tree-optimization/104119
* gcc.dg/tree-ssa/builtin-snprintf-13.c: New test.
* gcc.dg/tree-ssa/builtin-sprintf-warn-29.c: New test.

Fortran: reject simplifying TRANSFER for MOLD with storage size 0

gcc/fortran/ChangeLog:

PR fortran/104311
* check.cc (gfc_calculate_transfer_sizes): Checks for case when
storage size of SOURCE is greater than zero while the storage size
of MOLD is zero and MOLD is an array shall not depend on SIZE.

gcc/testsuite/ChangeLog:

PR fortran/104311
* gfortran.dg/transfer_simplify_15.f90: New test.

Speed up fixincludes.

In my case:
$ rm ./stmp-fixinc ; time make -j16

takes 17 seconds, where I can reduce it easily with the suggested
change. Then I get to 11.2 seconds.

The scripts searches ~2500 folders in my case with total 20K header
files.

fixincludes/ChangeLog:

* fixinc.in: Use mkdir -p rather that a loop.

rs6000: Remove -m[no-]fold-gimple flag [PR103686]

The -m[no-]fold-gimple flag was really intended primarily for internal
testing while implementing GIMPLE folding for rs6000 vector built-in
functions.  It ended up leaking into other places, causing problems such
as PR103686 identifies.  Let's remove it.

There are a number of tests in the testsuite that require adjustment.
Some specify -mfold-gimple directly, which is the default, so that is
handled by removing the option.  Others unnecessarily specify
-mno-fold-gimple, as the tests work fine without this.  Again that is
handled by removing the option.  There are a couple of extra variants of
tests specifically for -mno-fold-gimple; for those, we can just remove the
whole test.

gcc.target/powerpc/builtins-1.c was more problematic.  It was written in
such a way as to be extremely fragile.  For this one, I rewrote the whole
test in a different style, using individual functions to test each
built-in function.  These same tests are also largely covered by
builtins-1-be-folded.c and builtins-1-le-folded.c, so I chose to
explicitly make this test -mbig for simplicity, and use -O2 for clean code
generation.  I made some slight modifications to the expected instruction
counts as a result, and tested on both 32- and 64-bit.

2022-02-02  Bill Schmidt  <wschmidt@linux.ibm.com>

gcc/
PR target/103686
* config/rs6000/rs6000-builtin.cc (rs6000_gimple_fold_builtin): Remove
test for !rs6000_fold_gimple.
* config/rs6000/rs6000.cc (rs6000_option_override_internal): Likewise.
* config/rs6000/rs6000.opt (mfold-gimple): Remove.

gcc/testsuite/
PR target/103686
* gcc.target/powerpc/builtins-1-be-folded.c: Remove -mfold-gimple
option.
* gcc.target/powerpc/builtins-1-le-folded.c: Likewise.
* gcc.target/powerpc/builtins-1.c: Rewrite to use small functions and
restrict to -O2 -mbig for predictability.  Adjust instruction counts.
* gcc.target/powerpc/builtins-5.c: Remove -mno-fold-gimple option.
* gcc.target/powerpc/p8-vec-xl-xst.c: Likewise.
* gcc.target/powerpc/pr83926.c: Likewise.
* gcc.target/powerpc/pr86731-nogimplefold-longlong.c: Delete.
* gcc.target/powerpc/pr86731-nogimplefold.c: Delete.
* gcc.target/powerpc/swaps-p8-17.c: Remove -mno-fold-gimple option.

rs6000: Fix LE code gen for vec_cnt[lt]z_lsbb [PR95082]

These built-ins were misimplemented as always having big-endian semantics.

2022-01-18  Bill Schmidt  <wschmidt@linux.ibm.com>

gcc/
PR target/95082
* config/rs6000/rs6000-builtin.cc (rs6000_expand_builtin): Handle
endianness for vclzlsbb and vctzlsbb.
* config/rs6000/rs6000-builtins.def (VCLZLSBB_V16QI): Change
default pattern and indicate a different pattern will be used for
big endian.
(VCLZLSBB_V4SI): Likewise.
(VCLZLSBB_V8HI): Likewise.
(VCTZLSBB_V16QI): Likewise.
(VCTZLSBB_V4SI): Likewise.
(VCTZLSBB_V8HI): Likewise.

gcc/testsuite/
PR target/95082
* gcc.target/powerpc/vsu/vec-cntlz-lsbb-0.c: Restrict to -mbig.
* gcc.target/powerpc/vsu/vec-cntlz-lsbb-1.c: Likewise.
* gcc.target/powerpc/vsu/vec-cntlz-lsbb-3.c: New.
* gcc.target/powerpc/vsu/vec-cntlz-lsbb-4.c: New.
* gcc.target/powerpc/vsu/vec-cnttz-lsbb-0.c: Restrict to -mbig.
* gcc.target/powerpc/vsu/vec-cnttz-lsbb-1.c: Likewise.
* gcc.target/powerpc/vsu/vec-cnttz-lsbb-3.c: New.
* gcc.target/powerpc/vsu/vec-cnttz-lsbb-4.c: New.

rs6000: Consolidate target built-ins code

Continuing with the refactoring effort, this patch moves as much of the
target-specific built-in support code into a new file, rs6000-builtin.cc.
However, we can't easily move the overloading support code out of
rs6000-c.cc, because the build machinery understands that as a special file
to be included with the C and C++ front ends.

This patch is just a straightforward move, with one exception.  I found
that the builtin_mode_to_type[] array is no longer used, so I also removed
all code having to do with it.

The code in rs6000-builtin.cc is organized in related sections:
 - General support functions
 - Initialization support
 - GIMPLE folding support
 - Expansion support

Overloading support remains in rs6000-c.cc.

2022-02-03  Bill Schmidt  <wschmidt@linux.ibm.com>

gcc/
* config.gcc (powerpc*-*-*): Add rs6000-builtin.o to extra_objs.
* config/rs6000/rs6000-builtin.cc: New file, containing code moved
from other files.
* config/rs6000/rs6000-call.cc (cpu_is_info): Move to
rs6000-builtin.cc.
(cpu_supports_info): Likewise.
(rs6000_type_string): Likewise.
(altivec_expand_predicate_builtin): Likewise.
(rs6000_htm_spr_icode): Likewise.
(altivec_expand_vec_init_builtin): Likewise.
(get_element_number): Likewise.
(altivec_expand_vec_set_builtin): Likewise.
(altivec_expand_vec_ext_builtin): Likewise.
(rs6000_invalid_builtin): Likewise.
(rs6000_fold_builtin): Likewise.
(fold_build_vec_cmp): Likewise.
(fold_compare_helper): Likewise.
(map_to_integral_tree_type): Likewise.
(fold_mergehl_helper): Likewise.
(fold_mergeeo_helper): Likewise.
(rs6000_builtin_valid_without_lhs): Likewise.
(rs6000_builtin_is_supported): Likewise.
(rs6000_gimple_fold_mma_builtin): Likewise.
(rs6000_gimple_fold_builtin): Likewise.
(rs6000_expand_ldst_mask): Likewise.
(cpu_expand_builtin): Likewise.
(elemrev_icode): Likewise.
(ldv_expand_builtin): Likewise.
(lxvrse_expand_builtin): Likewise.
(lxvrze_expand_builtin): Likewise.
(stv_expand_builtin): Likewise.
(mma_expand_builtin): Likewise.
(htm_spr_num): Likewise.
(htm_expand_builtin): Likewise.
(rs6000_expand_builtin): Likewise.
(rs6000_vector_type): Likewise.
(rs6000_init_builtins): Likewise.  Remove initialization of
builtin_mode_to_type entries.
(rs6000_builtin_decl): Move to rs6000-builtin.cc.
* config/rs6000/rs6000.cc (rs6000_builtin_mask_for_load): New
external declaration.
(rs6000_builtin_md_vectorized_function): Likewise.
(rs6000_builtin_reciprocal): Likewise.
(altivec_builtin_mask_for_load): Move to rs6000-builtin.cc.
(rs6000_builtin_types): Likewise.
(builtin_mode_to_type): Remove.
(rs6000_builtin_mask_for_load): Move to rs6000-builtin.cc.  Remove
static qualifier.
(rs6000_builtin_md_vectorized_function): Likewise.
(rs6000_builtin_reciprocal): Likewise.
* config/rs6000/rs6000.h (builtin_mode_to_type): Remove.
* config/rs6000/t-rs6000 (rs6000-builtin.o): New target.

make `-Werror` optional in libatomic/libbacktrace/libgomp/libitm/libsanitizer

* `-Werror` can cause issues when a more recent version of GCC compiles
  an older version:
  - https://bugs.gentoo.org/229059
  - https://bugs.gentoo.org/475350
  - https://bugs.gentoo.org/667104

libatomic/ChangeLog:

* configure.ac: Support --disable-werror.
* configure: Regenerate.

libbacktrace/ChangeLog:

* configure.ac: Support --disable-werror.
* configure: Regenerate.

libgomp/ChangeLog:

* configure.ac: Support --disable-werror.
* configure: Regenerate.

libitm/ChangeLog:

* configure.ac: Support --disable-werror.
* configure: Regenerate.

libsanitizer/ChangeLog:

* configure.ac: Support --disable-werror.
* aclocal.m4: Include also ../config/warnings.m4.
* libbacktrace/Makefile.am (WARN_FLAGS): Remove.
* configure: Regenerate.
* Makefile.in: Regenerate.
* asan/Makefile.in: Regenerate.
* hwasan/Makefile.in: Regenerate.
* interception/Makefile.in: Regenerate.
* libbacktrace/Makefile.in: Regenerate.
* lsan/Makefile.in: Regenerate.
* sanitizer_common/Makefile.in: Regenerate.
* tsan/Makefile.in: Regenerate.
* ubsan/Makefile.in: Regenerate.

Co-Authored-By: Jakub Jelinek <jakub@redhat.com>

debug/104337 - avoid messing with the abstract origin chain in NRV

The following avoids NRV from massaging DECL_ABSTRACT_ORIGIN after
variable creation since NRV runs _after_ the function was inlined and thus
affects the inlined variables copy indirectly.  We may adjust the abstract
origin of a variable only at the point we create it, not further along the
path since otherwise the (new) invariant that the abstract origin is always
the ultimate origin cannot be maintained.

The intent of what NRV does is OK I guess and it may improve the debug
experience.  But I also notice we do

  SET_DECL_VALUE_EXPR (found, result);
  DECL_HAS_VALUE_EXPR_P (found) = 1;

the code is there since the merge from tree-ssa which added tree-nrv.c.

Jakub added the DECL_VALUE_EXPR in g:938650d8fddb878f623e315f0b7fd94b217efa96
and Jason added the abstract origin setting conditional in g:7716876bbd3a

The follwoing takes the radical approach and remove the attempt
to "optimize" the debug info.

The gdb testsuites show no regressions.

2022-02-03  Richard Biener  <rguenther@suse.de>

PR debug/104337
* tree-nrv.cc (pass_nrv::execute): Remove tieing result and found
together via DECL_ABSTRACT_ORIGIN.

* gcc.dg/debug/pr104337.c: New testcase.

rs6000: Unify error messages for built-in constant restrictions

We currently give different error messages for built-in functions that
violate range restrictions on their arguments, depending on whether we
record them as requiring an n-bit literal or a literal between two values.
It's better to be consistent.  Change the error message for the n-bit
literal to look like the other one.

2022-02-02  Bill Schmidt  <wschmidt@linux.ibm.com>

gcc/
* config/rs6000/rs6000-call.cc (rs6000_expand_builtin): Revise error
message for RES_BITS case.

gcc/testsuite/
* gcc.target/powerpc/bfp/scalar-test-data-class-10.c: Adjust error
messages.
* gcc.target/powerpc/bfp/scalar-test-data-class-2.c: Likewise.
* gcc.target/powerpc/bfp/scalar-test-data-class-3.c: Likewise.
* gcc.target/powerpc/bfp/scalar-test-data-class-4.c: Likewise.
* gcc.target/powerpc/bfp/scalar-test-data-class-5.c: Likewise.
* gcc.target/powerpc/bfp/scalar-test-data-class-9.c: Likewise.
* gcc.target/powerpc/bfp/vec-test-data-class-4.c: Likewise.
* gcc.target/powerpc/bfp/vec-test-data-class-5.c: Likewise.
* gcc.target/powerpc/bfp/vec-test-data-class-6.c: Likewise.
* gcc.target/powerpc/bfp/vec-test-data-class-7.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-12.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-14.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-17.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-19.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-2.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-22.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-24.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-27.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-29.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-32.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-34.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-37.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-39.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-4.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-42.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-44.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-47.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-49.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-52.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-54.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-57.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-59.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-62.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-64.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-67.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-69.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-7.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-72.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-74.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-77.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-79.c: Likewise.
* gcc.target/powerpc/dfp/dtstsfi-9.c: Likewise.
* gcc.target/powerpc/pr80315-1.c: Likewise.
* gcc.target/powerpc/pr80315-2.c: Likewise.
* gcc.target/powerpc/pr80315-3.c: Likewise.
* gcc.target/powerpc/pr80315-4.c: Likewise.
* gcc.target/powerpc/pr82015.c: Likewise.
* gcc.target/powerpc/pr91903.c: Likewise.
* gcc.target/powerpc/test_fpscr_rn_builtin_error.c: Likewise.
* gcc.target/powerpc/vec-ternarylogic-10.c: Likewise.

ranger: fix small thinko in fur_list constructor

The fur_list constructor for two ranges is leaving [1] in an undefined
state.  The reason we haven't noticed is because after all the
shuffling in the last cycle there are no remaining users of it
(similarly for fur_list(unsigned, irange *)).

Since it's very late in the cycle, I would prefer to fix this, rather
than removing unused constructors altogether.  Besides, we have uses
of them queued up for the next release.

gcc/ChangeLog:

* gimple-range-fold.cc (fur_list::fur_list): Set m_local[1] correctly.

arm: Fix up help.exp regression

On Thu, Jan 20, 2022 at 11:27:20AM +0000, Richard Earnshaw via Gcc-patches wrote:
> gcc/ChangeLog:
>
>       * config/arm/arm.opt (mfix-cortex-a57-aes-1742098): New command-line
>       option.
>       (mfix-cortex-a72-aes-1655431): New option alias.

> --- a/gcc/config/arm/arm.opt
> +++ b/gcc/config/arm/arm.opt
> @@ -272,6 +272,16 @@ mfix-cmse-cve-2021-35465
>  Target Var(fix_vlldm) Init(2)
>  Mitigate issues with VLLDM on some M-profile devices (CVE-2021-35465).
>
> +mfix-cortex-a57-aes-1742098
> +Target Var(fix_aes_erratum_1742098) Init(2) Save
> +Mitigate issues with AES instructions on Cortex-A57 and Cortex-A72.
> +Arm erratum #1742098
> +
> +mfix-cortex-a72-aes-1655431
> +Target Alias(mfix-cortex-a57-aes-1742098)
> +Mitigate issues with AES instructions on Cortex-A57 and Cortex-A72.
> +Arm erratum #1655431
> +
>  munaligned-access
>  Target Var(unaligned_access) Init(2) Save
>  Enable unaligned word and halfword accesses to packed data.

This breaks:
Running /usr/src/gcc/gcc/testsuite/gcc.misc-tests/help.exp ...
FAIL: compiler driver --help=target option(s): "^ +-.*[^:.]$" absent from output: "  -mfix-cortex-a57-aes-1742098 Mitigate issues with AES instructions on Cortex-A57 and Cortex-A72. Arm erratum #1742098"

help.exp with help of lib/options.exp tests whether all non-empty descriptions of
options are terminated with . or :.

2022-02-03  Jakub Jelinek  <jakub@redhat.com>

* config/arm/arm.opt (mfix-cortex-a57-aes-1742098,
mfix-cortex-a72-aes-1655431): Ensure description ends with full stop.

Assert that backedges are available in path solver.

gcc/ChangeLog:

* cfganal.cc (verify_marked_backedges): New.
* cfganal.h (verify_marked_backedges): New.
* gimple-range-path.cc (path_range_query::path_range_query):
Verify freshness of back edges.
* tree-ssa-loop-ch.cc (ch_base::copy_headers): Call
mark_dfs_back_edges.
* tree-ssa-threadbackward.cc (back_threader::back_threader): Move
path_range_query construction after backedges have been
updated.

Skip gnat.dg/div_zero.adb on PowerPC

The hardware instruction does not trap on divide by zero there.

gcc/testsuite
PR tree-optimization/104356
* gnat.dg/div_zero.adb: Add dg-skip-if directive for PowerPC.

aarch64: Remove struct_vect_25.c XFAILs

At some point we started generating the intended code for
aarch64/sve/struct_vect_25.c.  This patch removes the xfails
and the scan-assembler-times that replaced the xfailed forms.

gcc/testsuite/
* gcc.target/aarch64/sve/struct_vect_25.c: Remove XFAILs.

aarch64: Adjust tests after fix for PR102659

After the fix for PR102659, the vectoriser can no longer group
conditional accesses of the form:

  for (int i = 0; i < n; ++i)
    if (...)
      ...a[i * 2] + a[i * 2 + 1]...;

on LP64 targets.  It has to treat them as two independent
gathers instead.

This was causing failures in the sve mask_struct*.c tests.
The tests weren't really testing that int iterators could
be used, so this patch switches to pointer-sized iterators
instead.

gcc/testsuite/
* gcc.target/aarch64/sve/mask_struct_load_1.c: Use intptr_t
iterators instead of int iterators.
* gcc.target/aarch64/sve/mask_struct_load_2.c: Likewise.
* gcc.target/aarch64/sve/mask_struct_load_3.c: Likewise.
* gcc.target/aarch64/sve/mask_struct_load_4.c: Likewise.
* gcc.target/aarch64/sve/mask_struct_load_5.c: Likewise.
* gcc.target/aarch64/sve/mask_struct_load_6.c: Likewise.
* gcc.target/aarch64/sve/mask_struct_load_7.c: Likewise.
* gcc.target/aarch64/sve/mask_struct_load_8.c: Likewise.
* gcc.target/aarch64/sve/mask_struct_store_1.c: Likewise.
* gcc.target/aarch64/sve/mask_struct_store_2.c: Likewise.
* gcc.target/aarch64/sve/mask_struct_store_3.c: Likewise.
* gcc.target/aarch64/sve/mask_struct_store_4.c: Likewise.

aarch64: Add missing movmisalign patterns

The Advanced SIMD movmisalign patterns didn't handle 16-bit
FP modes, which meant that the vector loop for:

  void
  test (_Float16 *data)
  {
    _Pragma ("omp simd")
    for (int i = 0; i < 8; ++i)
      data[i] = 1.0;
  }

would be versioned for alignment.

This was causing some new failures in aarch64/sve/single_5.c:

FAIL: gcc.target/aarch64/sve/single_5.c scan-assembler-not \\tb
FAIL: gcc.target/aarch64/sve/single_5.c scan-assembler-not \\tcmp
FAIL: gcc.target/aarch64/sve/single_5.c scan-assembler-times \\tstr\\tq[0-9]+, 10

but I didn't look into what changed from earlier releases.
Adding the missing modes removes some existing xfails.

gcc/
* config/aarch64/aarch64-simd.md (movmisalign<mode>): Extend from
VALL to VALL_F16.

gcc/testsuite/
* gcc.target/aarch64/sve/single_5.c: Remove some XFAILs.

aarch64: Remove VALL_F16MOV iterator

The VALL_F16MOV iterator now has the same modes as VALL_F16,
in the same order.  This patch removes the former in favour
of the latter.

This doesn't fix a bug as such, but it's ultra-safe (no change in
object code) and it saves a follow-up patch from having to make
a false choice between the iterators.

gcc/
* config/aarch64/iterators.md (VALL_F16MOV): Delete.
* config/aarch64/aarch64-simd.md (mov<mode>): Use VALL_F16 instead
of VALL_F16MOV.

testsuite: Remove TSVC XFAILs for SVE

Many of the XFAILed TSVC tests pass for SVE.  This patch updates
the markup accordingly.

gcc/testsuite/
* gcc.dg/vect/tsvc/vect-tsvc-s1115.c: Don't XFAIL for SVE.
* gcc.dg/vect/tsvc/vect-tsvc-s114.c: Likewise.
* gcc.dg/vect/tsvc/vect-tsvc-s1161.c: Likewise.
* gcc.dg/vect/tsvc/vect-tsvc-s1232.c: Likewise.
* gcc.dg/vect/tsvc/vect-tsvc-s124.c: Likewise.
* gcc.dg/vect/tsvc/vect-tsvc-s1279.c: Likewise.
* gcc.dg/vect/tsvc/vect-tsvc-s161.c: Likewise.
* gcc.dg/vect/tsvc/vect-tsvc-s253.c: Likewise.
* gcc.dg/vect/tsvc/vect-tsvc-s257.c: Likewise.
* gcc.dg/vect/tsvc/vect-tsvc-s271.c: Likewise.
* gcc.dg/vect/tsvc/vect-tsvc-s2711.c: Likewise.
* gcc.dg/vect/tsvc/vect-tsvc-s2712.c: Likewise.
* gcc.dg/vect/tsvc/vect-tsvc-s272.c: Likewise.
* gcc.dg/vect/tsvc/vect-tsvc-s273.c: Likewise.
* gcc.dg/vect/tsvc/vect-tsvc-s274.c: Likewise.
* gcc.dg/vect/tsvc/vect-tsvc-s276.c: Likewise.
* gcc.dg/vect/tsvc/vect-tsvc-s278.c: Likewise.
* gcc.dg/vect/tsvc/vect-tsvc-s279.c: Likewise.
* gcc.dg/vect/tsvc/vect-tsvc-s3111.c: Likewise.
* gcc.dg/vect/tsvc/vect-tsvc-s4113.c: Likewise.
* gcc.dg/vect/tsvc/vect-tsvc-s441.c: Likewise.
* gcc.dg/vect/tsvc/vect-tsvc-s443.c: Likewise.
* gcc.dg/vect/tsvc/vect-tsvc-s491.c: Likewise.
* gcc.dg/vect/tsvc/vect-tsvc-vas.c: Likewise.
* gcc.dg/vect/tsvc/vect-tsvc-vif.c: Likewise.

testsuite: Update guality xfails for aarch64*-*-*

Following on from GCC 11 patch g:f31ddad8ac8, this one gives clean
guality.exp test results for aarch64-linux-gnu with modern gdb
(this time gdb 11.2).

The justification is the same as previously:

------
For people using older gdbs, it will trade one set of noisy results for
another set.  I still think it's better to have the xfails based on
one “clean” and “modern” run rather than have FAILs and XPASSes for
all runs.

It's hard to tell which of these results are aarch64-specific and
which aren't.  If other target maintainers want to do something similar,
and are prepared to assume the same gdb version, then it should become
clearer over time which ones are target-specific and which aren't.

There are no new skips here, so changes in test results will still
show up as XPASSes.

I've not analysed the failures or filed PRs for them.  In some
ways the guality directory itself seems like the best place to
start looking for xfails, if someone's interested in working
in this area.
------

gcc/testsuite/
* gcc.dg/guality/ipa-sra-1.c: Update aarch64*-*-* xfails.
* gcc.dg/guality/pr54519-1.c: Likewise.
* gcc.dg/guality/pr54519-3.c: Likewise.

Fix wording for: attribute ‘-xyz’ argument ‘target’ is unknown

gcc/ChangeLog:

* config/i386/i386-options.cc (ix86_valid_target_attribute_inner_p):
Change subject and object in the error message.
* config/s390/s390.cc (s390_valid_target_attribute_inner_p):
Likewise.

s390x: Fix one more -Wformat-diag.

gcc/ChangeLog:

* config/s390/s390.cc (s390_valid_target_attribute_inner_p):
Use the error message for i386 target.

ranger: Fix up wi_fold_in_parts for small precision types [PR104334]

The wide-int.h templates expect that when an int/long etc. operand is used
it will be sign-extended based on the types precision.
wi_fold_in_parts passes 3 such non-zero constants to wi::lt_p, wi::gt_p
and wi::eq_p - 1, 3 and 4, which means it was doing weird things if either
some of 1, 3 or 4 weren't representable in type, or if type was unsigned 3 bit
type 4 should be written as -4.
The following patch promotes the subtraction operands to widest_int and
uses that as the type for ?h_range variables and compares them as such.
We don't need the overflow handling because there is never an overflow.

2022-02-02  Jakub Jelinek  <jakub@redhat.com>

PR tree-optimization/104334
* range-op.cc (range_operator::wi_fold_in_parts): Change lh_range
and rh_range type to widest_int and subtract in widest_int.  Remove
ov_rh, ov_lh and sign vars, always perform comparisons as signed
and use >, < and == operators for it.

* g++.dg/opt/pr104334.C: New test.

openmp, fortran: Improve !$omp atomic checks [PR104328]

The testcase shows some cases that weren't verified and we ICE on
invalid because of that.
One problem is that unlike before, we weren't checking if some expression
is EXPR_VARIABLE with non-NULL symtree in the case where there was
a conversion around it.
The other two issues is that we check that in an IF ->block is non-NULL
and then immediately dereference ->block->next->op, but on invalid
code with no statements in the then clause ->block->next might be NULL.

2022-02-02  Jakub Jelinek  <jakub@redhat.com>

PR fortran/104328
* openmp.cc (is_scalar_intrinsic_expr): If must_be_var && conv_ok
and expr is conversion, verify it is a conversion from EXPR_VARIABLE
with non-NULL symtree.  Check ->block->next before dereferencing it.

* gfortran.dg/gomp/atomic-27.f90: New test.

c++: dependent array bounds completion [PR104302]

The patch for PR55227 changed the minimal init-list handling in
cp_complete_array_type to a call to reshape_init, which broke on the
dependent initializer.  It occurred to me that trying to deduce the array
size from a dependent init-list is wrong in general, so let's just not.  I
also limited the reshape_init call to the case of a char array, as before
the patch for 55227; that's the only case where we want to strip a level of
braces from an array.

PR c++/104302

gcc/cp/ChangeLog:

* decl.cc (maybe_deduce_size_from_array_init): Give up
on type-dependent init.
(cp_complete_array_type): Only call reshape_init for character
array.

gcc/testsuite/ChangeLog:

* g++.dg/template/array35.C: New test.
* g++.dg/template/array36.C: New test.

Correct typos in -Wuse-after-free description.

gcc/ChangeLog:
* common.opt (-Wuse-after-free): Correct typos.

Daily bump.

docs: mention analyzer interaction with -ftrivial-auto-var-init [PR104270]

gcc/ChangeLog:
PR analyzer/104270
* doc/invoke.texi (-ftrivial-auto-var-init=): Add reference to
-Wanalyzer-use-of-uninitialized-value to paragraph documenting that
-ftrivial-auto-var-init= doesn't suppress warnings.

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

rs6000/testsuite: Return 0 for powerpc_altivec_ok on other targets

2022-02-02  Segher Boessenkool  <segher@kernel.crashing.org>

gcc/testsuite/
* lib/target-supports.exp (check_effective_target_powerpc_altivec_ok):
Return 0 if the target is not Power.  Restructure and add some comments.

libstdc++: Fix -Wunused-variable warning for -fno-exceptions build

If _GLIBCXX_THROW_OR_ABORT expands to just __builtin_abort() then the
bool variable used in the filesystem_error constructor is unused. Mark
it as maybe_unused to there's no warning for -fno-exceptions builds.

libstdc++-v3/ChangeLog:

* src/c++17/fs_dir.cc (fs::recursive_directory_iterator::pop):
Add [[maybe_unused]] attribute.
* src/filesystem/dir.cc (fs::recursive_directory_iterator::pop):
Likewise.

libstdc++: Fix invalid instantiations in tests

These tests instantiate std::multiset and std::set with a type that has
no operator< so they should use a custom comparison function.

libstdc++-v3/ChangeLog:

* testsuite/23_containers/multiset/operators/cmp_c++20.cc: Use
custom comparison function for multiset.
* testsuite/23_containers/set/operators/cmp_c++20.cc: Use custom
comparison function for set.

libstdc++: Fix link failure in _OutputIteratorConcept

The C++98-style concept check for output iterators causes a link
failure on mingw-w64, because the __val() member function isn't defined.
Change it to use a function pointer instead. That pointer is never set
to anything meaningful, but it doesn't matter as the __constraints()
function only has to be instantiated, it's never called.

We could refactor all of these to use unevaluated contexts (e.g. sizeof
of __decltype) so that we only check the expressions are well-formed,
without any codegen at all. Any improvements to these are very low
priority though.

libstdc++-v3/ChangeLog:

* include/bits/boost_concept_check.h (_OutputIteratorConcept):
Change member function to data member of function pointer type.

lto: fix error handling for -Wl,-plugin-opt=debug

When one uses something like: -Wl,-plugin-opt=debug,
we end up with lto1 WPA invocation that has 'debug'
on command line. We interpret that as input filename.

The patch moves resolution checking later so that we end up with
a reasonable error message:

lto1: fatal error: open debug failed: No such file or directory
compilation terminated.

PR lto/104333

gcc/lto/ChangeLog:

* lto-common.cc (read_cgraph_and_symbols): Move resolution
checking for number of files later and report a reasonable
error message.
* lto-object.cc (lto_obj_file_open): Make error fatal.

Remove dead macro: TEXT_SECTION_NAME

gcc/ChangeLog:

* dwarf2out.cc (TEXT_SECTION_NAME): Remove unused macro.

analyzer: fix missing check for uninit of return values

When moving the -fanalyzer tests for -ftrivial-auto-var-init to the
"torture" subdirectory of gcc.dg/analyzer I noticed that -fanalyzer
wasn't always properly checking for initialization of return values.

The issue was that some "return" handling was using
region_model::copy_region to copy to the RESULT_DECL, and copy_region
wasn't checking for poisoned svalues.

This patch eliminates region_model::copy_region in favor of simply
doing a get_ravlue/set_value pair, fixing the issue.

gcc/analyzer/ChangeLog:
* region-model.cc (region_model::on_return): Replace usage of
copy_region with get_rvalue/set_value pair.
(region_model::pop_frame): Likewise.
(selftest::test_compound_assignment): Likewise.
* region-model.h (region_model::copy_region): Delete decl.
* region.cc (region_model::copy_region): Delete.

gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/torture/ubsan-1.c: Add missing return stmts.
* gcc.dg/analyzer/uninit-trivial-auto-var-init-pattern.c: Move
to...
* gcc.dg/analyzer/torture/uninit-trivial-auto-var-init-pattern.c:
...here.
* gcc.dg/analyzer/uninit-trivial-auto-var-init-uninitialized.c:
Move to...
* gcc.dg/analyzer/torture/uninit-trivial-auto-var-init-uninitialized.c:
...here.
* gcc.dg/analyzer/uninit-trivial-auto-var-init-zero.c: Move to...
* gcc.dg/analyzer/torture/uninit-trivial-auto-var-init-zero.c: ...here.

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

analyzer: consolidate duplicate code in region::calc_offset

gcc/analyzer/ChangeLog:
* region.cc (region::calc_offset): Consolidate effectively
identical cases.

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

analyzer: implement bit_range_region

GCC 12 has gained -Wanalyzer-use-of-uninitialized-value, and I'm
seeing various false positives from it due to region_model::get_lvalue
not properly handling BIT_FIELD_REF, and falling back to
using an UNKNOWN_REGION for them.

This patch fixes these false positives by implementing a new
bit_range_region region subclass for handling BIT_FIELD_REF.

gcc/analyzer/ChangeLog:
* analyzer.h (class bit_range_region): New forward decl.
* region-model-manager.cc (region_model_manager::get_bit_range):
New.
(region_model_manager::log_stats): Handle m_bit_range_regions.
* region-model.cc (region_model::get_lvalue_1): Handle
BIT_FIELD_REF.
* region-model.h (region_model_manager::get_bit_range): New decl.
(region_model_manager::m_bit_range_regions): New field.
* region.cc (region::get_base_region): Handle RK_BIT_RANGE.
(region::base_region_p): Likewise.
(region::calc_offset): Likewise.
(bit_range_region::dump_to_pp): New.
(bit_range_region::get_byte_size): New.
(bit_range_region::get_bit_size): New.
(bit_range_region::get_byte_size_sval): New.
(bit_range_region::get_relative_concrete_offset): New.
* region.h (enum region_kind): Add RK_BIT_RANGE.
(region::dyn_cast_bit_range_region): New vfunc.
(class bit_range_region): New.
(is_a_helper <const bit_range_region *>::test): New.
(default_hash_traits<bit_range_region::key_t>): New.

gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/torture/uninit-bit-field-ref.c: New test.

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

analyzer: stop -ftrivial-auto-var-init from suppressing uninit warnings [PR104270]

GCC 12 has gained two features for dealing with uninitialized variables:

(a) a new -Wanalyzer-use-of-uninitialized-value warning within -fanalyzer
for interprocedural path-sensitive detection of ununit uses, and

(b) a new -ftrivial-auto-var-init option for mitigating some uses of
uninit variables

It turns out that using (b) was thwarting (a), as it led to -fanalyzer
seeing calls to IFN_DEFERRED_INIT, which -fanalyzer wasn't
special-casing, thus treating it as initializing the variables in
question, and thus silencing -Wanalyzer-use-of-uninitialized-value on
them.

invoke.texi says:

"GCC still considers an automatic variable that doesn't have an explicit
initializer as uninitialized, @option{-Wuninitialized} will still report
warning messages on such automatic variables."

and thus -Wanalyzer-use-of-uninitialized-value ought to as well.

This patch adds special-case handling to -fanalyzer for
IFN_DEFERRED_INIT,  so that -fanalyzer will warn on uninit uses of
variables that are mitigated by -ftrivial-auto-var-init.

gcc/analyzer/ChangeLog:
PR analyzer/104270
* region-model.cc (region_model::on_call_pre): Handle
IFN_DEFERRED_INIT.

gcc/testsuite/ChangeLog:
PR analyzer/104270
* gcc.dg/analyzer/uninit-trivial-auto-var-init-pattern.c: New
test.
* gcc.dg/analyzer/uninit-trivial-auto-var-init-uninitialized.c:
New test.
* gcc.dg/analyzer/uninit-trivial-auto-var-init-zero.c: New test.

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

gcc: define _REENTRANT for OpenRISC when -pthread is passed

The detection of pthread support fails on OpenRISC unless _REENTRANT
is defined. Added the CPP_SPEC definition to correct this.

gcc/ChangeLog:

PR target/94372
* config/or1k/linux.h (CPP_SPEC): Define.

Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>

AArch32: use canonical ordering for complex mul, fma and fms

After the first patch in the series this updates the optabs to expect the
canonical sequence.

gcc/ChangeLog:

PR tree-optimization/102819
PR tree-optimization/103169
* config/arm/vec-common.md (cml<fcmac1><conj_op><mode>4): Use
canonical order.

AArch64: use canonical ordering for complex mul, fma and fms

After the first patch in the series this updates the optabs to expect the
canonical sequence.

gcc/ChangeLog:

PR tree-optimization/102819
PR tree-optimization/103169
* config/aarch64/aarch64-simd.md (cml<fcmac1><conj_op><mode>4): Use
canonical order.
* config/aarch64/aarch64-sve.md (cml<fcmac1><conj_op><mode>4): Likewise.

vect: Simplify and extend the complex numbers validation routines.

This patch boosts the analysis for complex mul,fma and fms in order to ensure
that it doesn't create an incorrect output.

Essentially it adds an extra verification to check that the two nodes it's going
to combine do the same operations on compatible values.  The reason it needs to
do this is that if one computation differs from the other then with the current
implementation we have no way to deal with it since we have to remove the
permute.

When we can keep the permute around we can probably handle these by unrolling.

While implementing this since I have to do the traversal anyway I took advantage
of it by simplifying the code a bit.  Previously we would determine whether
something is a conjugate and then try to figure out which conjugate it is and
then try to see if the permutes match what we expect.

Now the code that does the traversal will detect this in one go and return to us
whether the operation is something that can be combined and whether a conjugate
is present.

Secondly because it does this I can now simplify the checking code itself to
essentially just try to apply fixed patterns to each operation.

The patterns represent the order operations should appear in. For instance a
complex MUL operation combines :

  Left 1 + Right 1
  Left 2 + Right 2

with a permute on the nodes consisting of:

  { Even, Even } + { Odd, Odd  }
  { Even, Odd  } + { Odd, Even }

By abstracting over these patterns the checking code becomes quite simple.

As part of this I was checking the order of the operands which was left in
"slp" order. as in, the same order they showed up in during SLP, which means
that the accumulator is first.  However it looks like I didn't document this
and the x86 optab was implemented assuming the same order as FMA, i.e. that
the accumulator is last.

I have this changed the order to match that of FMA and FMS which corrects the
x86 codegen and will update the Arm targets.  This has now also been
documented.

gcc/ChangeLog:

PR tree-optimization/102819
PR tree-optimization/103169
* doc/md.texi: Update docs for cfms, cfma.
* tree-data-ref.h (same_data_refs): Accept optional offset.
* tree-vect-slp-patterns.cc (is_linear_load_p): Fix issue with repeating
patterns.
(vect_normalize_conj_loc): Remove.
(is_eq_or_top): Change to take two nodes.
(enum _conj_status, compatible_complex_nodes_p,
vect_validate_multiplication): New.
(class complex_add_pattern, complex_add_pattern::matches,
complex_add_pattern::recognize, class complex_mul_pattern,
complex_mul_pattern::recognize, class complex_fms_pattern,
complex_fms_pattern::recognize, class complex_operations_pattern,
complex_operations_pattern::recognize, addsub_pattern::recognize): Pass
new cache.
(complex_fms_pattern::matches, complex_mul_pattern::matches): Pass new
cache and use new validation code.
* tree-vect-slp.cc (vect_match_slp_patterns_2, vect_match_slp_patterns,
vect_analyze_slp): Pass along cache.
(compatible_calls_p): Expose.
* tree-vectorizer.h (compatible_calls_p, slp_node_hash,
slp_compat_nodes_map_t): New.
(class vect_pattern): Update signatures include new cache.

gcc/testsuite/ChangeLog:

PR tree-optimization/102819
PR tree-optimization/103169
* g++.dg/vect/pr99149.cc: xfail for now.
* gcc.dg/vect/complex/pr102819-1.c: New test.
* gcc.dg/vect/complex/pr102819-2.c: New test.
* gcc.dg/vect/complex/pr102819-3.c: New test.
* gcc.dg/vect/complex/pr102819-4.c: New test.
* gcc.dg/vect/complex/pr102819-5.c: New test.
* gcc.dg/vect/complex/pr102819-6.c: New test.
* gcc.dg/vect/complex/pr102819-7.c: New test.
* gcc.dg/vect/complex/pr102819-8.c: New test.
* gcc.dg/vect/complex/pr102819-9.c: New test.
* gcc.dg/vect/complex/pr103169.c: New test.

Declare std::array members with attribute const [PR101831].

Resolves:
PR libstdc++/101831 - Spurious maybe-uninitialized warning on std::array::size

libstdc++-v3/ChangeLog:

PR libstdc++/101831
* include/std/array (begin): Declare const member function attribute
const.
(end, rbegin, rend, size, max_size, empty, data): Same.
* testsuite/23_containers/array/capacity/empty.cc: Add test cases.
* testsuite/23_containers/array/capacity/max_size.cc: Same.
* testsuite/23_containers/array/capacity/size.cc: Same.
* testsuite/23_containers/array/iterators/begin_end.cc: New test.

cris: Reload using special-regs before general-regs

On code where reload has an effect (i.e. quite rarely, just enough to be
noticeable), this change gets code quality back to the situation prior
to "Remove CRIS v32 ACR artefacts".  We had from IRA a pseudoregister
marked to be reloaded from a union of all allocatable registers (here:
SPEC_GENNONACR_REGS) but where the register-class corresponding to the
constraint for the register-type alternative (here: GENERAL_REGS) was
*not* a subset of that class: SPEC_GENNONACR_REGS (and GENNONACR_REGS)
had a one-register "hole" for the ACR register, a register present in
GENERAL_REGS.

Code in reload.cc:find_reloads adds 4 to the cost of a register-type
alternative that is neither a subset of the preferred register class nor
vice versa and thus reload thinks it can't use.  It would be preferable
to look for a non-empty intersection of the two, and use that
intersection for that alternative, something that can't be expressed
because a register class can't be formed from a random register set.

The effect was here that the GENERAL_REGS to/from memory alternatives
("r") had their cost raised such that the SPECIAL_REGS alternatives
("x") looked better.  This happened to improve code quality just a
little bit compared to GENERAL_REGS being chosen.

Anyway, with the improved CRIS register-class topology, the
subset-checking code no longer has the GENERAL_REGS-demoting effect.
To get the same quality, we have to adjust the port such that
SPECIAL_REGS are specifically preferred when possible and advisible,
i.e. when there's at least two of those registers as for the CPU variant
with multiplication (which happens to be the variant maintained for
performance).

For the move-pattern, the obvious method may seem to simply "curse" the
constraints of some alternatives (by prepending one of the "?!^$"
characters) but that method can't be used, because we want the effect to
be conditional on the CPU variant.  It'd also be a shame to split the
"*movsi_internal<setcc><setnz><setnzvc>" into two CPU-variants (with
different cursing).  Iterators would help, but it still seems unwieldy.
Instead, add copies of the GENERAL_REGS variants (to the SPECIAL_REGS
alternatives) on the "other" side, and make use of the "enabled"
attribute to activate just the desired order of alternatives.

gcc:

* config/cris/cris.cc (cris_preferred_reload_class): Reject
"eliminated" registers and small-enough constants unless
reloaded into a class that is a subset of GENERAL_REGS.
* config/cris/cris.md (attribute "cpu_variant"): New.
(attribute "enabled"): Conditionalize on a matching attribute
cpu_variant, if specified.
("*movsi_internal<setcc><setnz><setnzvc>"): For moves to and from
memory, add cpu-variant-enabled variants for "r" alternatives on
the far side of the "x" alternatives, preferring the "x" ones
only for variants where MOF is present (in addition to SRP).

cris: Don't discriminate against ALL_REGS in TARGET_REGISTER_MOVE_COST

When the tightest class including both SPECIAL_REGS and GENERAL_REGS
is ALL_REGS, artificially special-casing for *either* to or from, hits
artificially hard.  This gets the port back to the code quality before
the previous patch ("cris: Remove CRIS v32 ACR artefacts") - except
for_vfprintf_r and _vfiprintf_r in newlib (still .8 and .4% larger).

gcc:
* config/cris/cris.cc (cris_register_move_cost): Remove special pre-ira
extra cost for ALL_REGS.

cris: Remove CRIS v32 ACR artefacts

This is the change to which I alluded to this in r11-220 /
d0780379c1b6 as "causes extra register moves in libgcc".  It has
unfortunate side-effects due to the change in register-class topology.
There's a slight improvement in coremark numbers (< 0.07%) though also
increase in code size total (< 0.7%) but looking at the individual
changes in functions, it's all-over (-7..+7%).  Looking specifically
at functions that improved in speed, it's also both plus and minus in
code sizes.  It's unworkable to separate improvements from regressions
for this case.  I'll follow up with patches to restore the previous
code quality, in both size and speed.

gcc:
* config/cris/constraints.md (define_register_constraint "b"): Now
GENERAL_REGS.
* config/cris/cris.md (CRIS_ACR_REGNUM): Remove.
* config/cris/cris.h: (reg_class, REG_CLASS_NAMES)
(REG_CLASS_CONTENTS): Remove ACR_REGS, SPEC_ACR_REGS, GENNONACR_REGS,
and SPEC_GENNONACR_REGS.
* config/cris/cris.cc (cris_preferred_reload_class): Don't mention
ACR_REGS and return GENERAL_REGS instead of GENNONACR_REGS.

cris: For expanded movsi, don't match operands we know will be reloaded

In a session investigating unexpected fallout from a change, I
noticed reload needs one operand being a register to make an
informed decision.  It can happen that there's just a constant
and a memory operand, as in:

(insn 668 667 42 104 (parallel [
            (set (mem:SI (plus:SI (reg/v/f:SI 347 [ fs ])
                        (const_int 168 [0xa8])) \
 [1 fs_126(D)->regs.cfa_how+0 S4 A8])
                (const_int 2 [0x2]))
            (clobber (reg:CC 19 dccr))
        ]) "<...>/gcc/libgcc/unwind-dw2.c":1121:21 22 {*movsi_internal}
     (expr_list:REG_UNUSED (reg:CC 19 dccr)
        (nil)))

This was helpfully created by combine.  When this happens,
reload can't check for costs and preferred register classes,
(both operands will start with NO_REGS as the preferred class)
and will default to the constraints order in the insn in reload.
(Which also does its own temporary merge in find_reloads, but
that's a different story.)  Better don't match the simple cases.
Beware that subregs have to be matched.

I'm doing this just for word_mode (SI) for now, but may repeat
this for the other valid modes as well.  In particular, that
goes for DImode as I see the expanded movdi does *almost* this,
but uses register_operand instead of REG_S_P (from cris.h).
Using REG_S_P is the right choice here because register_operand
also matches (subreg (mem ...)  ...) *until* reload is done.
By itself it's just a sub-0.1% performance win (coremark).

Also removing a stale comment.

gcc:
* config/cris/cris.md ("*movsi_internal<setcc><setnz><setnzvc>"):
Conditionalize on (sub-)register operands or operand 1 being 0.

cris: Don't default to -mmul-bug-workaround

This flips the default for the errata handling for an old version
(TL;DR: workaround: no multiply instruction last on a cache-line).
Newer versions of the CRIS cpu don't have that bug.  While the impact
of the workaround is very marginal (coremark: less than .05% larger,
less than .0005% slower) it's an irritating pseudorandom factor when
assessing the impact of other changes.

Also, fix a wart requiring changes to more than TARGET_DEFAULT to flip
the default.

People building old kernels or operating systems to run on
ETRAX 100 LX are advised to pass "-mmul-bug-workaround".

gcc:
* config/cris/cris.h (TARGET_DEFAULT): Don't include MASK_MUL_BUG.
(MUL_BUG_ASM_DEFAULT): New macro.
(MAYBE_AS_NO_MUL_BUG_ABORT): Define in terms of MUL_BUG_ASM_DEFAULT.
* doc/invoke.texi (CRIS Options, -mmul-bug-workaround): Adjust
accordingly.

Daily bump.

libstdc++: Do not use dirent::d_type unconditionally

These new tests should not use the d_type member unless it's actually
present on the OS.

libstdc++-v3/ChangeLog:

* testsuite/27_io/filesystem/iterators/error_reporting.cc: Use
autoconf macro to check whether d_type is present.
* testsuite/experimental/filesystem/iterators/error_reporting.cc:
Likewise.

AutoFDO: don't set param_early_inliner_max_iterations to 10.

param_early_inliner_max_iterations specifies the maximum number
of nested indirect inlining iterations performed by early inliner.
Normally, the default value is 1.

For AutoFDO this parameter was also used as the number of iteration for
its indirect call promotion loop and the default value was set to 10.
While it makes sense to have 10 in the indirect call promotion loop
(we want to make the IR match the profiled binary before actual annotation)
there is no reason to have a special default value for the
regular early inliner.

This change removes the special AutoFDO default value setting for
param_early_inliner_max_iterations while keeping 10 as the number of
iterations for the AutoFDO indirect call promotion loop.

This change improves a simple fibonacci benchmark in AutoFDO mode
by 15% on x86_64-pc-linux-gnu.

Tested on x86_64-pc-linux-gnu.

gcc/ChangeLog:
* auto-profile.cc (auto_profile): Hard-code the number of iterations (10).

gcc/ChangeLog:
* opts.cc (common_handle_option): Don't set param_early_inliner_max_iterations
to 10 for AutoFDO.

[COMMITTED] Change multiprecision.org to use https

As reported at
https://gcc.gnu.org/pipermail/gcc/2022-February/238216.html,
multiprecision.org now uses https so this updates the documentation
to use https instead of http.

Committed as obvious.

gcc/ChangeLog:

* doc/install.texi:

libstdc++: Add more tests for filesystem directory iterators

The PR 97731 test was added to verify a fix to the Filesystem TS code,
but we should also have the same test to avoid similar regressions in
the C++17 std::filesystem code.

Also add tests for directory_options::follow_directory_symlink

libstdc++-v3/ChangeLog:

* testsuite/27_io/filesystem/iterators/97731.cc: New test.
* testsuite/27_io/filesystem/iterators/recursive_directory_iterator.cc:
Check follow_directory_symlink option.
* testsuite/experimental/filesystem/iterators/recursive_directory_iterator.cc:
Likewise.

libstdc++: Reset filesystem::recursive_directory_iterator on error

The standard requires directory iterators to become equal to the end
iterator value if they report an error. Some members functions of
filesystem::recursive_directory_iterator fail to do that.

libstdc++-v3/ChangeLog:

* src/c++17/fs_dir.cc (recursive_directory_iterator::increment):
Reset state to past-the-end iterator on error.
(fs::recursive_directory_iterator::pop(error_code&)): Likewise.
(fs::recursive_directory_iterator::pop()): Check _M_dirs before
it might get reset.
* src/filesystem/dir.cc (recursive_directory_iterator): Likewise,
for the TS implementation.
* testsuite/27_io/filesystem/iterators/error_reporting.cc: New test.
* testsuite/experimental/filesystem/iterators/error_reporting.cc: New test.

libstdc++: Fix doxygen comment for filesystem::perms operators

libstdc++-v3/ChangeLog:

* include/bits/fs_fwd.h (filesystem::perms): Fix comment.

libstdc++: Improve config output for --enable-cstdio [PR104301]

Currently we just print "checking for underlying I/O to use... stdio"
unconditionally, whether configured to use stdio_pure or stdio_posix. We
should make it clear that the user's configure option chose the right
thing.

libstdc++-v3/ChangeLog:

PR libstdc++/104301
* acinclude.m4 (GLIBCXX_ENABLE_CSTDIO): Print different messages
for stdio_pure and stdio_posix options.
* configure: Regenerate.

IBM Z: fix `section type conflict` with -mindirect-branch-table

s390_code_end () puts indirect branch tables into separate sections and
tries to switch back to wherever it was in the beginning by calling
switch_to_section (current_function_section ()).

First of all, this is unnecessary - the other backends don't do it.

Furthermore, at this time there is no current function, but if the
last processed function was cold, in_cold_section_p remains set.  This
causes targetm.asm_out.function_section () to call
targetm.section_type_flags (), which in absence of current function
decl classifies the section as SECTION_WRITE.  This causes a section
type conflict with the existing SECTION_CODE.

gcc/ChangeLog:

* config/s390/s390.cc (s390_code_end): Do not switch back to
code section.

gcc/testsuite/ChangeLog:

* gcc.target/s390/nobp-section-type-conflict.c: New test.

Fortran: error recovery when simplifying EOSHIFT

gcc/fortran/ChangeLog:

PR fortran/104331
* simplify.cc (gfc_simplify_eoshift): Avoid NULL pointer
dereference when shape is not set.

gcc/testsuite/ChangeLog:

PR fortran/104331
* gfortran.dg/eoshift_9.f90: New test.

libcpp: Fix up padding handling in funlike_invocation_p [PR104147]

As mentioned in the PR, in some cases we preprocess incorrectly when we
encounter an identifier which is defined as function-like macro, followed
by at least 2 CPP_PADDING tokens and then some other identifier.
On the following testcase, the problem is in the 3rd funlike_invocation_p,
the tokens are CPP_NAME Y, CPP_PADDING (the pfile->avoid_paste shared token),
CPP_PADDING (one created with padding_token, val.source is non-NULL and
val.source->flags & PREV_WHITE is non-zero) and then another CPP_NAME.
funlike_invocation_p remembers there was a padding token, but remembers the
first one because of its condition, then the next token is the CPP_NAME,
which is not CPP_OPEN_PAREN, so the CPP_NAME token is backed up, but as we
can't easily backup more tokens, it pushes into a new context the padding
token (the pfile->avoid_paste one).  The net effect is that when Y is not
defined as fun-like macro, we read Y, avoid_paste, padding_token, Y,
while if Y is fun-like macro, we read Y, avoid_paste, avoid_paste, Y
(the second avoid_paste is because that is how we handle end of a context).
Now, for stringify_arg that is unfortunately a significant difference,
which handles CPP_PADDING tokens with:
      if (token->type == CPP_PADDING)
        {
          if (source == NULL
              || (!(source->flags & PREV_WHITE)
                  && token->val.source == NULL))
            source = token->val.source;
          continue;
        }
and later on
      /* Leading white space?  */
      if (dest - 1 != BUFF_FRONT (pfile->u_buff))
        {
          if (source == NULL)
            source = token;
          if (source->flags & PREV_WHITE)
            *dest++ = ' ';
        }
      source = NULL;
(and c-ppoutput.cc has similar code).
So, when Y is not fun-like macro, ' ' is added because padding_token's
val.source->flags & PREV_WHITE is non-zero, while when it is fun-like
macro, we don't add ' ' in between, because source is NULL and so
used from the next token (CPP_NAME Y), which doesn't have PREV_WHITE set.

Now, the funlike_invocation_p condition
       if (padding == NULL
           || (!(padding->flags & PREV_WHITE) && token->val.source == NULL))
        padding = token;
looks very similar to that in stringify_arg/c-ppoutput.cc, so I assume
the intent was to prefer do the same thing and pick the right padding.
But there are significant differences.  Both stringify_arg and c-ppoutput.cc
don't remember the CPP_PADDING token, but its val.source instead, while
in funlike_invocation_p we want to remember the padding token that has the
significant information for stringify_arg/c-ppoutput.cc.
So, IMHO we want to overwrite padding if:
1) padding == NULL (remember that there was any padding at all)
2) padding->val.source == NULL (this matches the source == NULL
   case in stringify_arg)
3) !(padding->val.source->flags & PREV_WHITE) && token->val.source == NULL
   (this matches the !(source->flags & PREV_WHITE) && token->val.source == NULL
   case in stringify_arg)

2022-02-01  Jakub Jelinek  <jakub@redhat.com>

PR preprocessor/104147
* macro.cc (funlike_invocation_p): For padding prefer a token
with val.source non-NULL especially if it has PREV_WHITE set
on val.source->flags.  Add gcc_assert that CPP_PADDING tokens
don't have PREV_WHITE set in flags.

* c-c++-common/cpp/pr104147.c: New test.

libcpp: Avoid PREV_WHITE and other random content on CPP_PADDING tokens

The funlike_invocation_p macro never triggered, the other
asserts did on some tests, see below for a full list.
This seems to be caused by #pragma/_Pragma handling.
do_pragma does:
          pfile->directive_result.src_loc = pragma_token_virt_loc;
          pfile->directive_result.type = CPP_PRAGMA;
          pfile->directive_result.flags = pragma_token->flags;
          pfile->directive_result.val.pragma = p->u.ident;
when it sees a pragma, while start_directive does:
  pfile->directive_result.type = CPP_PADDING;
and so does _cpp_do__Pragma.
Now, for #pragma lex.cc will just ignore directive_result if
it has CPP_PADDING type:
              if (_cpp_handle_directive (pfile, result->flags & PREV_WHITE))
                {
                  if (pfile->directive_result.type == CPP_PADDING)
                    continue;
                  result = &pfile->directive_result;
                }
but destringize_and_run does not:
  if (pfile->directive_result.type == CPP_PRAGMA)
    {
...
    }
  else
    {
      count = 1;
      toks = XNEW (cpp_token);
      toks[0] = pfile->directive_result;
and from there it will copy type member of CPP_PADDING, but all the
other members from the last CPP_PRAGMA before it.
Small testcase for it with no option (at least no -fopenmp or -fopenmp-simd).
 #pragma GCC push_options
 #pragma GCC ignored "-Wformat"
 #pragma GCC pop_options
void
foo ()
{
  _Pragma ("omp simd")
  for (int i = 0; i < 64; i++)
    ;
}

Here is a patch that replaces those
      toks = XNEW (cpp_token);
      toks[0] = pfile->directive_result;
lines with
      toks = &pfile->avoid_paste;

2022-02-01  Jakub Jelinek  <jakub@redhat.com>

* directives.cc (destringize_and_run): Push &pfile->avoid_paste
instead of a copy of pfile->directive_result for the CPP_PADDING
case.

rs6000: Fix up PCH on powerpc* [PR104323]

As mentioned in the PR and as can be seen on:
--- gcc/testsuite/gcc.dg/pch/pr104323-1.c.jj 2022-02-01 13:06:00.163192414 +0100
+++ gcc/testsuite/gcc.dg/pch/pr104323-1.c 2022-02-01 13:13:41.226712735 +0100
@@ -0,0 +1,16 @@
+/* PR target/104323 */
+/* { dg-require-effective-target powerpc_altivec_ok } */
+/* { dg-options "-maltivec" } */
+
+#include "pr104323-1.h"
+
+__vector int a1 = { 100, 200, 300, 400 };
+__vector int a2 = { 500, 600, 700, 800 };
+__vector int r;
+
+int
+main ()
+{
+  r = vec_add (a1, a2);
+  return 0;
+}
--- gcc/testsuite/gcc.dg/pch/pr104323-1.hs.jj 2022-02-01 13:06:03.180149978 +0100
+++ gcc/testsuite/gcc.dg/pch/pr104323-1.hs 2022-02-01 13:12:30.175706620 +0100
@@ -0,0 +1,5 @@
+/* PR target/104323 */
+/* { dg-require-effective-target powerpc_altivec_ok } */
+/* { dg-options "-maltivec" } */
+
+#include <altivec.h>
testcase which I'm not including into testsuite because for some reason
the test fails on non-powerpc* targets (is done even on those and fails
because of missing altivec.h etc.), PCH is broken on powerpc*-*-* since the
new builtin generator has been introduced.
The generator contains or emits comments like:
  /* #### Cannot mark this as a GC root because only pointer types can
     be marked as GTY((user)) and be GC roots.  All trees in here are
     kept alive by other globals, so not a big deal.  Alternatively,
     we could change the enum fields to ints and cast them in and out
     to avoid requiring a GTY((user)) designation, but that seems
     unnecessarily gross.  */
Having the fntypes stored in other GC roots can work fine for GC,
ggc_collect will then always mark them and so they won't disappear from
the tables, but it definitely doesn't work for PCH, which when the
arrays with fntype members aren't GTY marked means on PCH write we create
copies of those FUNCTION_TYPEs and store in *.gch that the GC roots should
be updated, but don't store that rs6000_builtin_info[?].fntype etc. should
be updated.  When PCH is read again, the blob is read at some other address,
GC roots are updated, rs6000_builtin_info[?].fntype contains garbage
pointers (GC freed pointers with random data, or random unrelated types or
other trees).
The following patch fixes that.  It stops any user markings because that
is totally unnecessary, just skips fields we don't need to mark and adds
GTY(()) to the 2 array variables.  We can get rid of all those global
vars for the fn types, they can be now automatic vars.
With the patch we get
  {
    &rs6000_instance_info[0].fntype,
    1 * (RS6000_INST_MAX),
    sizeof (rs6000_instance_info[0]),
    &gt_ggc_mx_tree_node,
    &gt_pch_nx_tree_node
  },
  {
    &rs6000_builtin_info[0].fntype,
    1 * (RS6000_BIF_MAX),
    sizeof (rs6000_builtin_info[0]),
    &gt_ggc_mx_tree_node,
    &gt_pch_nx_tree_node
  },
as the new roots which is exactly what we want and significantly more
compact than countless
  {
    &uv2di_ftype_pudi_usi,
    1,
    sizeof (uv2di_ftype_pudi_usi),
    &gt_ggc_mx_tree_node,
    &gt_pch_nx_tree_node
  },
  {
    &uv2di_ftype_lg_puv2di,
    1,
    sizeof (uv2di_ftype_lg_puv2di),
    &gt_ggc_mx_tree_node,
    &gt_pch_nx_tree_node
  },
  {
    &uv2di_ftype_lg_pudi,
    1,
    sizeof (uv2di_ftype_lg_pudi),
    &gt_ggc_mx_tree_node,
    &gt_pch_nx_tree_node
  },
  {
    &uv2di_ftype_di_puv2di,
    1,
    sizeof (uv2di_ftype_di_puv2di),
    &gt_ggc_mx_tree_node,
    &gt_pch_nx_tree_node
  },
cases (822 of these instead of just those 4 shown).

2022-02-01  Jakub Jelinek  <jakub@redhat.com>

PR target/104323
* config/rs6000/t-rs6000 (EXTRA_GTYPE_DEPS): Append rs6000-builtins.h
rather than $(srcdir)/config/rs6000/rs6000-builtins.def.
* config/rs6000/rs6000-gen-builtins.cc (write_decls): Don't use
GTY((user)) for struct bifdata and struct ovlddata.  Instead add
GTY((skip(""))) to members with pointer and enum types that don't need
to be tracked.  Add GTY(()) to rs6000_builtin_info and rs6000_instance_info
declarations.  Don't emit gt_ggc_mx and gt_pch_nx declarations.
(write_extern_fntype, write_fntype): Remove.
(write_fntype_init): Emit the fntype vars as automatic vars instead
of file scope ones.
(write_header_file): Don't iterate with write_extern_fntype.
(write_init_file): Don't iterate with write_fntype.  Don't emit
gt_ggc_mx and gt_pch_nx definitions.

c++: lambda in template default argument [PR103186]

The problem with this testcase was that since my patch for PR97900 we
weren't preserving DECL_UID identity for parameters of instantiations of
templated functions, so using those parameters as the keys for the
defarg_inst map broke.  I think this was always fragile given the
possibility of redeclarations, so instead of reverting that change let's
switch to keying off the function.

Memory use compiling stdc++.h is not noticeably different.

PR c++/103186

gcc/cp/ChangeLog:

* pt.cc (defarg_inst): Use tree_vec_map_cache_hasher.
(defarg_insts_for): New.
(tsubst_default_argument): Adjust.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/lambda/lambda-defarg10.C: New test.

tree: move tree_vec_map_cache_hasher into header

gcc/ChangeLog:

* tree.h (struct tree_vec_map_cache_hasher): Move from...
* tree.cc (struct tree_vec_map_cache_hasher): ...here.

[nvptx] Add uniform_warp_check insn

On a GT 1030, with driver version 470.94 and -mptx=3.1 I run into:
...
FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/parallel-dims.c \
  -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none \
  -O2 execution test
...
which minimizes to the same test-case as listed in commit "[nvptx]
Update default ptx isa to 6.3".

The problem is again that the first diverging branch is not handled as such in
SASS, which causes problems with a subsequent shfl insn, but given that we
have -mptx=3.1 we can't use the bar.warp.sync insn.

Given that the default is now -mptx=6.3, and consequently -mptx=3.1 is of a
lesser importance, implement the next best thing: abort when detecting
non-convergence using this insn:
...
  { .reg.b32 act;
    vote.ballot.b32 act,1;
    .reg.pred uni;
    setp.eq.b32 uni,act,0xffffffff;
    @ !uni trap;
    @ !uni exit;
  }
...

Interestingly, the effect of this is that rather than aborting, the test-case
now passes.

Tested on x86_64 with nvptx accelerator.

gcc/ChangeLog:

2022-01-31  Tom de Vries  <tdevries@suse.de>

* config/nvptx/nvptx.cc (nvptx_single): Use nvptx_uniform_warp_check.
* config/nvptx/nvptx.md (define_c_enum "unspecv"): Add
UNSPECV_UNIFORM_WARP_CHECK.
(define_insn "nvptx_uniform_warp_check"): New define_insn.

[nvptx] Add bar.warp.sync

On a GT 1030 (sm_61), with driver version 470.94 I run into:
...
FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/parallel-dims.c \
  -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none \
  -O2 execution test
...
which minimizes to the same test-case as listed in commit "[nvptx] Update
default ptx isa to 6.3".

The first divergent branch looks like:
...
  {
    .reg .u32 %x;
    mov.u32 %x,%tid.x;
    setp.ne.u32 %r59,%x,0;
  }
  @ %r59 bra $L15;
  mov.u64 %r48,%ar0;
  mov.u32 %r22,2;
  ld.u64 %r53,[%r48];
  mov.u32 %r55,%r22;
  mov.u32 %r54,1;
 $L15:
...
and when inspecting the generated SASS, the branch is not setup as a divergent
branch, but instead as a regular branch.

This causes us to execute a shfl.sync insn in divergent mode, which is likely
to cause trouble given a remark in the ptx isa version 6.3, which mentions
that for .target sm_6x or below, all threads must excute the same
shfl.sync instruction in convergence.

Fix this by placing a "bar.warp.sync 0xffffffff" at the desired convergence
point (in the example above, after $L15).

Tested on x86_64 with nvptx accelerator.

gcc/ChangeLog:

2022-01-31  Tom de Vries  <tdevries@suse.de>

* config/nvptx/nvptx.cc (nvptx_single): Use nvptx_warpsync.
* config/nvptx/nvptx.md (define_c_enum "unspecv"): Add
UNSPECV_WARPSYNC.
(define_insn "nvptx_warpsync"): New define_insn.

[nvptx] Update default ptx isa to 6.3

With the following example, minimized from parallel-dims.c:
...
int
main (void)
{
  int vectors_max = -1;
  #pragma acc parallel num_gangs (1) num_workers (1) copy (vectors_max)
  {
    for (int i = 0; i < 2; i++)
      for (int j = 0; j < 2; j++)
        #pragma acc loop vector reduction (max: vectors_max)
        for (int k = 0; k < 32; k++)
          vectors_max = k;
  }

  if (vectors_max != 31)
    __builtin_abort ();

  return 0;
}
...
I run into (T400, driver version 470.94):
...
FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/parallel-dims.c \
  -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none -O2 \
  execution test
...
The FAIL does not happen with GOMP_NVPTX_JIT=-O0.

The problem seems to be that the shfl insns for the vector reduction are not
executed uniformly by the warp.  Enforcing this by using shfl.sync fixes the
problem.

Fix this by setting the ptx isa to 6.3 by default, which allows the use of
shfl.sync.

Tested on x86_64 with nvptx accelerator.

gcc/ChangeLog:

2022-01-27  Tom de Vries  <tdevries@suse.de>

* config/nvptx/nvptx.opt (mptx): Set to PTX_VERSION_6_3 by default.

[nvptx] Update bar.sync for ptx isa 6.0

In ptx isa 6.0, a new barrier instruction was added, and bar.sync was
redefined as barrier.sync.aligned.

The aligned modifier indicates that all threads in a CTA will execute the same
barrier instruction.

The seems fine for a form "bar.sync 0".

But a "bar.sync %rx,64" (as used for vector length > 32) may execute a
diffferent barrier depending on the value of %rx, so we can't assume it's
aligned.

Fix this by using "barrier.sync %rx,64" instead.

Tested on x86_64 with nvptx accelerator.

gcc/ChangeLog:

2022-01-27  Tom de Vries  <tdevries@suse.de>

* config/nvptx/nvptx-opts.h (enum ptx_version): Add PTX_VERSION_6_0.
* config/nvptx/nvptx.h (TARGET_PTX_6_0): New macro.
* config/nvptx/nvptx.md (define_insn "nvptx_barsync"): Use barrier
insn for TARGET_PTX_6_0.

[nvptx] Handle nop in prevent_branch_around_nothing

When running libgomp test-case reduction-7.c on an nvptx accelerator
(T400, driver version 470.86) and GOMP_NVPTX_JIT=-O0, I run into:
...
reduction-7.exe:reduction-7.c:312: v_p_2: \
  Assertion `out[j * 32 + i] == (i + j) * 2' failed.
FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/reduction-7.c \
  -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none \
  -O0  execution test
...

During investigation I found ptx code like this:
...
@ %r163 bra $L262;
$L262:
...

There's a known problem with executing this type of code, and a workaround is
in place to address this: prevent_branch_around_nothing.  The workaround does
not trigger though because it doesn't handle the nop insn.

Fix this by handling the nop insn in prevent_branch_around_nothing.

Tested libgomp on x86_64 with nvptx accelerator.

gcc/ChangeLog:

2022-01-27  Tom de Vries  <tdevries@suse.de>

PR target/100428
* config/nvptx/nvptx.cc (prevent_branch_around_nothing): Handle nop
insn.

[nvptx] Add some support for .local atomics

The ptx insn atom doesn't support local memory.  In case of doing an atomic
operation on local memory, we run into:
...
operation not supported on global/shared address space
...
This is the cuGetErrorString message for CUDA_ERROR_INVALID_ADDRESS_SPACE.

The message is somewhat confusing given that actually the operation is not
supported on local address space.

Fix this by falling back on a non-atomic version when detecting
a frame-related memory operand.

This only solves some cases that are detected at compile-time.  It does
however fix the openacc private-atomic-* test-cases.

Tested on x86_64 with nvptx accelerator.

gcc/ChangeLog:

2022-01-27  Tom de Vries  <tdevries@suse.de>

* config/nvptx/nvptx.md (define_insn "atomic_compare_and_swap<mode>_1")
(define_insn "atomic_exchange<mode>")
(define_insn "atomic_fetch_add<mode>")
(define_insn "atomic_fetch_addsf")
(define_insn "atomic_fetch_<logic><mode>"): Output non-atomic version
if memory operands is frame-relative.

gcc/testsuite/ChangeLog:

2022-01-31  Tom de Vries  <tdevries@suse.de>

* gcc.target/nvptx/stack-atomics-run.c: New test.

libgomp/ChangeLog:

2022-01-27  Tom de Vries  <tdevries@suse.de>

* testsuite/libgomp.oacc-c-c++-common/private-atomic-1.c: Remove
PR83812 workaround.
* testsuite/libgomp.oacc-fortran/private-atomic-1-vector.f90: Same.
* testsuite/libgomp.oacc-fortran/private-atomic-1-worker.f90: Same.

[nvptx] Fix reduction lock

When I run the libgomp test-case reduction-cplx-dbl.c on an nvptx accelerator
(T400, driver version 470.86), I run into:
...
FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/reduction-cplx-dbl.c \
  -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none  -O0  \
  execution test
FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/reduction-cplx-dbl.c \
  -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none  -O2  \
  execution test
...

The problem is in this code generated for a gang reduction:
...
$L39:
atom.global.cas.b32     %r59, [__reduction_lock], 0, 1;
setp.ne.u32     %r116, %r59, 0;
@%r116  bra     $L39;
ld.f64  %r60, [%r44];
ld.f64  %r61, [%r44+8];
ld.f64  %r64, [%r44];
ld.f64  %r65, [%r44+8];
add.f64 %r117, %r64, %r22;
add.f64 %r118, %r65, %r41;
st.f64  [%r44], %r117;
st.f64  [%r44+8], %r118;
atom.global.cas.b32     %r119, [__reduction_lock], 1, 0;
...
which is taking and releasing a lock, but missing the appropriate barriers to
protect the loads and store inside the lock.

Fix this by adding membar.gl barriers.

Likewise, add membar.cta barriers if we protect shared memory loads and
stores (even though the worker-partitioning part of the test-case is not
failing).

Tested on x86_64 with nvptx accelerator.

gcc/ChangeLog:

2022-01-27  Tom de Vries  <tdevries@suse.de>

* config/nvptx/nvptx.cc (enum nvptx_builtins): Add
NVPTX_BUILTIN_MEMBAR_GL and NVPTX_BUILTIN_MEMBAR_CTA.
(VOID): New macro.
(nvptx_init_builtins): Add MEMBAR_GL and MEMBAR_CTA.
(nvptx_expand_builtin): Handle NVPTX_BUILTIN_MEMBAR_GL and
NVPTX_BUILTIN_MEMBAR_CTA.
(nvptx_lockfull_update): Add level parameter.  Emit barriers.
(nvptx_reduction_update, nvptx_goacc_reduction_fini): Update call to
nvptx_lockfull_update.
* config/nvptx/nvptx.md (define_c_enum "unspecv"): Add
UNSPECV_MEMBAR_GL.
(define_expand "nvptx_membar_gl"): New expand.
(define_insn "*nvptx_membar_gl"): New insn.

Strengthen memory order for atomic<T>::wait/notify

This matches the memory order in libc++.

libstdc++-v3/ChangeLog:
* include/bits/atomic_wait.h: Change memory order from
Acquire/Release with relaxed loads to SeqCst+Release for
accesses to the waiter's count.

docs: remove --disable-stage1-checking from requirements

As the minimal GCC version that can build the current master
is 4.8, it does not make sense mentioning something for older
versions.

gcc/ChangeLog:

* doc/install.texi: Remove option for GCC < 4.8.

veclower: Fix up -fcompare-debug issue in expand_vector_comparison [PR104307]

The following testcase fails -fcompare-debug, because expand_vector_comparison
since r11-1786-g1ac9258cca8030745d3c0b8f63186f0adf0ebc27 sets
vec_cond_expr_only when it sees some use other than VEC_COND_EXPR that uses
the lhs in its condition.
Obviously we should ignore debug stmts when doing so, e.g. by not pushing
them to uses.
That would be a 2 liner change, but while looking at it, I'm also worried
about VEC_COND_EXPRs that would use the lhs in more than one operand,
like VEC_COND_EXPR <lhs, lhs, something> or VEC_COND_EXPR <lhs, something, lhs>
(sure, they ought to be folded, but what if they weren't).  Because if
something like that happens, then FOR_EACH_IMM_USE_FAST would push the same
stmt multiple times and expand_vector_condition can return true even when
it modifies it (for vector bool masking).
And lastly, it seems quite wasteful to safe_push statements that will just
cause vec_cond_expr_only = false; and break; in the second loop, both for
cases like 1000 immediate non-VEC_COND_EXPR uses and for cases like
999 VEC_COND_EXPRs with lhs in cond followed by a single non-VEC_COND_EXPR
use.  So this patch only pushes VEC_COND_EXPRs there.

2022-02-01  Jakub Jelinek  <jakub@redhat.com>

PR middle-end/104307
* tree-vect-generic.cc (expand_vector_comparison): Don't push debug
stmts to uses vector, just set vec_cond_expr_only to false for
non-VEC_COND_EXPRs instead of pushing them into uses.  Treat
VEC_COND_EXPRs that use lhs not just in rhs1, but rhs2 or rhs3 too
like non-VEC_COND_EXPRs.

* gcc.target/i386/pr104307.c: New test.

rs6000: Don't #ifdef "short" built-in names

It was recently pointed out that we get anomalous behavior when using
__attribute__((target)) to select a CPU.  As an example, when building for
-mcpu=power8 but using __attribute__((target("mcpu=power10")), it is legal
to call __builtin_vec_mod, but not vec_mod, even though these are
equivalent.  This is because the equivalence is established with a #define
that is guarded by #ifdef _ARCH_PWR10.

This goofy behavior occurs with both the old builtins support and the
new.  One of the goals of the new builtins support was to make sure all
appropriate interfaces are available using __attribute__((target)), so I
failed in this respect.  This patch corrects the problem by removing the
ifdef.  Note that in a few cases we use an ifdef in a way that can't be
overridden by __attribute__((target)), and we need to keep those.  For
example, #ifdef __PPU__ is still appropriate.

2022-01-06  Bill Schmidt  <wschmidt@linux.ibm.com>

gcc/
* config/rs6000/rs6000-overload.def (VEC_ABSD): Remove #ifdef token.
(VEC_BLENDV): Likewise.
(VEC_BPERM): Likewise.
(VEC_CFUGE): Likewise.
(VEC_CIPHER_BE): Likewise.
(VEC_CIPHERLAST_BE): Likewise.
(VEC_CLRL): Likewise.
(VEC_CLRR): Likewise.
(VEC_CMPNEZ): Likewise.
(VEC_CNTLZ): Likewise.
(VEC_CNTLZM): Likewise.
(VEC_CNTTZM): Likewise.
(VEC_CNTLZ_LSBB): Likewise.
(VEC_CNTM): Likewise.
(VEC_CNTTZ): Likewise.
(VEC_CNTTZ_LSBB): Likewise.
(VEC_CONVERT_4F32_8F16): Likewise.
(VEC_DIV): Likewise.
(VEC_DIVE): Likewise.
(VEC_EQV): Likewise.
(VEC_EXPANDM): Likewise.
(VEC_EXTRACT_FP_FROM_SHORTH): Likewise.
(VEC_EXTRACT_FP_FROM_SHORTL): Likewise.
(VEC_EXTRACTH): Likewise.
(VEC_EXTRACTL): Likewise.
(VEC_EXTRACTM): Likewise.
(VEC_EXTRACT4B): Likewise.
(VEC_EXTULX): Likewise.
(VEC_EXTURX): Likewise.
(VEC_FIRSTMATCHINDEX): Likewise.
(VEC_FIRSTMACHOREOSINDEX): Likewise.
(VEC_FIRSTMISMATCHINDEX): Likewise.
(VEC_FIRSTMISMATCHOREOSINDEX): Likewise.
(VEC_GB): Likewise.
(VEC_GENBM): Likewise.
(VEC_GENHM): Likewise.
(VEC_GENWM): Likewise.
(VEC_GENDM): Likewise.
(VEC_GENQM): Likewise.
(VEC_GENPCVM): Likewise.
(VEC_GNB): Likewise.
(VEC_INSERTH): Likewise.
(VEC_INSERTL): Likewise.
(VEC_INSERT4B): Likewise.
(VEC_LXVL): Likewise.
(VEC_MERGEE): Likewise.
(VEC_MERGEO): Likewise.
(VEC_MOD): Likewise.
(VEC_MSUB): Likewise.
(VEC_MULH): Likewise.
(VEC_NAND): Likewise.
(VEC_NCIPHER_BE): Likewise.
(VEC_NCIPHERLAST_BE): Likewise.
(VEC_NEARBYINT): Likewise.
(VEC_NMADD): Likewise.
(VEC_ORC): Likewise.
(VEC_PDEP): Likewise.
(VEC_PERMX): Likewise.
(VEC_PEXT): Likewise.
(VEC_POPCNT): Likewise.
(VEC_PARITY_LSBB): Likewise.
(VEC_REPLACE_ELT): Likewise.
(VEC_REPLACE_UN): Likewise.
(VEC_REVB): Likewise.
(VEC_RINT): Likewise.
(VEC_RLMI): Likewise.
(VEC_RLNM): Likewise.
(VEC_SBOX_BE): Likewise.
(VEC_SIGNEXTI): Likewise.
(VEC_SIGNEXTLL): Likewise.
(VEC_SIGNEXTQ): Likewise.
(VEC_SLDB): Likewise.
(VEC_SLV): Likewise.
(VEC_SPLATI): Likewise.
(VEC_SPLATID): Likewise.
(VEC_SPLATI_INS): Likewise.
(VEC_SQRT): Likewise.
(VEC_SRDB): Likewise.
(VEC_SRV): Likewise.
(VEC_STRIL): Likewise.
(VEC_STRIL_P): Likewise.
(VEC_STRIR): Likewise.
(VEC_STRIR_P): Likewise.
(VEC_STXVL): Likewise.
(VEC_TERNARYLOGIC): Likewise.
(VEC_TEST_LSBB_ALL_ONES): Likewise.
(VEC_TEST_LSBB_ALL_ZEROS): Likewise.
(VEC_VEE): Likewise.
(VEC_VES): Likewise.
(VEC_VIE): Likewise.
(VEC_VPRTYB): Likewise.
(VEC_VSCEEQ): Likewise.
(VEC_VSCEGT): Likewise.
(VEC_VSCELT): Likewise.
(VEC_VSCEUO): Likewise.
(VEC_VSEE): Likewise.
(VEC_VSES): Likewise.
(VEC_VSIE): Likewise.
(VEC_VSTDC): Likewise.
(VEC_VSTDCN): Likewise.
(VEC_VTDC): Likewise.
(VEC_XL): Likewise.
(VEC_XL_BE): Likewise.
(VEC_XL_LEN_R): Likewise.
(VEC_XL_SEXT): Likewise.
(VEC_XL_ZEXT): Likewise.
(VEC_XST): Likewise.
(VEC_XST_BE): Likewise.
(VEC_XST_LEN_R): Likewise.
(VEC_XST_TRUNC): Likewise.
(VEC_XXPERMDI): Likewise.
(VEC_XXSLDWI): Likewise.
(VEC_TSTSFI_EQ_DD): Likewise.
(VEC_TSTSFI_EQ_TD): Likewise.
(VEC_TSTSFI_GT_DD): Likewise.
(VEC_TSTSFI_GT_TD): Likewise.
(VEC_TSTSFI_LT_DD): Likewise.
(VEC_TSTSFI_LT_TD): Likewise.
(VEC_TSTSFI_OV_DD): Likewise.
(VEC_TSTSFI_OV_TD): Likewise.
(VEC_VADDCUQ): Likewise.
(VEC_VADDECUQ): Likewise.
(VEC_VADDEUQM): Likewise.
(VEC_VADDUDM): Likewise.
(VEC_VADDUQM): Likewise.
(VEC_VBPERMQ): Likewise.
(VEC_VCLZB): Likewise.
(VEC_VCLZD): Likewise.
(VEC_VCLZH): Likewise.
(VEC_VCLZW): Likewise.
(VEC_VCTZB): Likewise.
(VEC_VCTZD): Likewise.
(VEC_VCTZH): Likewise.
(VEC_VCTZW): Likewise.
(VEC_VEEDP): Likewise.
(VEC_VEESP): Likewise.
(VEC_VESDP): Likewise.
(VEC_VESSP): Likewise.
(VEC_VIEDP): Likewise.
(VEC_VIESP): Likewise.
(VEC_VPKSDSS): Likewise.
(VEC_VPKSDUS): Likewise.
(VEC_VPKUDUM): Likewise.
(VEC_VPKUDUS): Likewise.
(VEC_VPOPCNT): Likewise.
(VEC_VPOPCNTB): Likewise.
(VEC_VPOPCNTD): Likewise.
(VEC_VPOPCNTH): Likewise.
(VEC_VPOPCNTW): Likewise.
(VEC_VPRTYBD): Likewise.
(VEC_VPRTYBQ): Likewise.
(VEC_VPRTYBW): Likewise.
(VEC_VRLD): Likewise.
(VEC_VSLD): Likewise.
(VEC_VSRAD): Likewise.
(VEC_VSRD): Likewise.
(VEC_VSTDCDP): Likewise.
(VEC_VSTDCNDP): Likewise.
(VEC_VSTDCNQP): Likewise.
(VEC_VSTDCNSP): Likewise.
(VEC_VSTDCQP): Likewise.
(VEC_VSTDCSP): Likewise.
(VEC_VSUBECUQ): Likewise.
(VEC_VSUBEUQM): Likewise.
(VEC_VSUBUDM): Likewise.
(VEC_VSUBUQM): Likewise.
(VEC_VTDCDP): Likewise.
(VEC_VTDCSP): Likewise.
(VEC_VUPKHSW): Likewise.
(VEC_VUPKLSW): Likewise.

PR101260 regcprop: Add mode change check for copy reg

When propagating a multi-word register into an access with a smaller
mode the can_change_mode backend hook is already consulted for the
original register.  This however is also required for the intermediate
copy in copy_regno which might use a different register class.

gcc/ChangeLog:

PR rtl-optimization/101260
* regcprop.cc (maybe_mode_change): Invoke mode_change_ok also for
copy_regno.

gcc/testsuite/ChangeLog:

PR rtl-optimization/101260
* gcc.target/s390/pr101260.c: New testcase.

fold-const: do not fold NaN result from non-NaN operands [PR95115]

These operations should raise an invalid operation exception at runtime.
So they should not be folded during compilation unless -fno-trapping-math
is used.

gcc/
PR middle-end/95115
* fold-const.cc (const_binop): Do not fold NaN result from
  non-NaN operands.

gcc/testsuite
* gcc.dg/pr95115.c: New test.

[libgomp, testsuite] Fix insufficient resources in test-cases

When running libgomp test-case broadcast-many.c on an nvptx accelerator
(T400, driver version 470.86), I run into:
...
libgomp: The Nvidia accelerator has insufficient resources to launch \
  'main$_omp_fn$0' with num_workers = 32 and vector_length = 32; \
  recompile the program with 'num_workers = x and vector_length = y' on \
  that offloaded region or '-fopenacc-dim=:x:y' where x * y <= 896.

FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/broadcast-many.c \
  -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none  \
  -O0  execution test
...

The error does not occur when using GOMP_NVPTX_JIT=-O0.

Fix this by using 896 / 32 == 28 workers for ACC_DEVICE_TYPE_nvidia.

Likewise for some other test-cases.

Tested libgomp on x86_64 with nvptx accelerator.

libgomp/ChangeLog:

2022-01-27  Tom de Vries  <tdevries@suse.de>

* testsuite/libgomp.oacc-c-c++-common/broadcast-many.c: Reduce
num_workers for nvidia accelerator to fix libgomp error 'insufficient
resources'.
* testsuite/libgomp.oacc-c-c++-common/par-loop-comb-reduction-4.c:
Same.
* testsuite/libgomp.oacc-c-c++-common/reduction-7.c: Same.

[libgomp, testsuite] Reduce recursion depth in declare_target-*.f90

When running the libgomp testsuite with GOMP_NVPTX_JIT=-O0 using an nvptx
accelerator (Nvidia T400, 2GB), I run into:
...
libgomp: cuCtxSynchronize error: unspecified launch failure \
  (perhaps abort was called)

libgomp: cuMemFree_v2 error: unspecified launch failure

libgomp: device finalization failed
FAIL: libgomp.fortran/examples-4/declare_target-1.f90   -O0  execution test
...

The test-case contains:
...
  ! Reduced from 25 to 23, otherwise execution runs out of thread stack on
  ! Nvidia Titan V.
  if (fib (23) /= fib_wrapper (23)) stop 2
...

Fix this by reducing the fib/fib_wrapper argument from 23 to 22.

Same for declare_target-2.f90.

Tested on x86_64 with nvptx accelerator.

libgomp/ChangeLog:

2022-01-27  Tom de Vries  <tdevries@suse.de>

* testsuite/libgomp.fortran/examples-4/declare_target-1.f90: Reduce
recursion depth.
* testsuite/libgomp.fortran/examples-4/declare_target-2.f90: Same.

[ldist] Don't add lib calls with -fno-tree-loop-distribute-patterns

As mentioned in PR56888 comment 21:
...
-fno-tree-loop-distribute-patterns is the reliable way to not
transform loops into library calls.
...

However, since commit 6f966f06146 ("ldist: Recognize strlen and rawmemchr like
loops") a strlen or rawmemchr library call may be introduced by ldist.

This caused regressions in testcases
gcc.c-torture/execute/builtins/strlen{,-2,-3}.c for nvptx.

Fix this by not calling transform_reduction_loop from
loop_distribution::execute for -fno-tree-loop-distribute-patterns.

Tested regressed test-cases as well as gcc.dg/tree-ssa/ldist-*.c on
nvptx.

gcc/ChangeLog:

2022-01-31  Tom de Vries  <tdevries@suse.de>

* tree-loop-distribution.cc (generate_reduction_builtin_1): Check for
-ftree-loop-distribute-patterns.
(loop_distribution::execute): Don't call transform_reduction_loop for
-fno-tree-loop-distribute-patterns.

gcc/testsuite/ChangeLog:

2022-01-31  Tom de Vries  <tdevries@suse.de>

* gcc.dg/tree-ssa/ldist-strlen-4.c: New test.