c++: using operator= [PR105223]

In a template class A we normally add an implicit using A::operator= as a
placeholder for the implicitly declared operator whose signature we don't
know yet.  In my patch for PR92918 I stopped doing that if the class has an
explicit operator=, but that was wrong; an operator= taking an unrelated
type doesn't prevent the implicit declaration.

When I was working on that patch, the change was necessary to avoid another
regression, but apparently it is no longer needed.

PR c++/105223
PR c++/92918

gcc/cp/ChangeLog:

* class.cc (finish_struct): Always using op=.

gcc/testsuite/ChangeLog:

* g++.dg/template/using31.C: New test.

LoongArch: Fix bug for tmpdir-g++.dg-struct-layout-1/t033.

gcc/ChangeLog:

* config/loongarch/loongarch.cc: Fix bug for
tmpdir-g++.dg-struct-layout-1/t033.

Daily bump.

rs6000: Handle pcrel sibcalls to longcall functions [PR104894]

Before PCREL in POWER10, we were not allowed to perform sibcalls to longcall
functions since callee's return would skip the TOC restore in the caller.
However, with PCREL we can now safely perform a sibling call to longcall
functions.  The problem with the current code is that pcrel sibcall
branches to a PLT stub label even though -fno-plt was used.  The solution
here is to check for a pcrel longcall and emit an inline plt stub in
that case.

2022-04-11  Peter Bergner  <bergner@linux.ibm.com>

gcc/
PR target/104894
* config/rs6000/rs6000.cc (rs6000_sibcall_aix): Handle pcrel sibcalls
to longcall functions.

gcc/testsuite/
PR target/104894
* gcc.target/powerpc/pr104894.c: New test.
* gcc.target/powerpc/pr104894-2.c: New test.

ipa: fix comment typos

gcc/ChangeLog:

* ipa-free-lang-data.cc (free_lang_data_in_decl): Fix typos.

c++: operator new lookup [PR98249]

The standard says, as we quote in the comment just above, that if we don't
find operator new in the allocated type, it should be looked up in the
global scope.  This is specifically ::, not just any namespace, and we
already give an error for an operator new declared in any other namespace.

PR c++/98249

gcc/cp/ChangeLog:

* call.cc (build_operator_new_call): Just look in ::.

gcc/testsuite/ChangeLog:

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

libstdc++: Fix incorrect branch prediction hint in std::stacktrace

libstdc++-v3/ChangeLog:

* include/std/stacktrace (basic_stacktrace::_Impl::_M_allocate):
Change [[unlikely]] attribute to [[likely]].

rs6000: Fix unpack for no-direct-move (PR103623)

The _dm alternative works fine for soft-float, but the _nodm variant
pattern is missing that alternative.  So, let's add that.

There probably should be an r,r,i alternative as well (or we can make it
rm,r,i), but that is for later.

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

PR target/105213
PR target/103623
* config/rs6000/rs6000.md (unpack<mode>_nodm): Add m,r,i alternative.

phiopt: Fix up debug handling in the (x != cst1 ? x : cst2) != cst3 opt [PR105218]

In the PR104639 optimization, I've added code to emit
  # DEBUG D#1 => arg != carg ? arg : oarg
instruction and replace debug uses of the phi with that debug
temp, so that the debug info is still accurrate.
Unfortunately, that is only correct if the middle-bb and
phi bb contain 1 and 2 predecessors, i.e. the ones that
we are using in the optimization (in particular middle-bb has
cond-bb as pred and phi bb cond-bb and middle-bb).
If that is not the case, then we can reach these from another bb
and so the arg SSA_NAME might not be valid there (its definition
doesn't dominate all incoming edges), or, even if it is valid,
might be wrong-debug, e.g. phi argument from some unrelated other
incoming edge might have the carg value that the debug stmt
remaps to oarg.  In theory we could check for that case and
if middle-bb doesn't have a single pred or phi bb 2 preds
check if arg SSA_NAME dominates the phi bb and if all other
phi arguments are expr_not_equal_to the carg value, but this patch
just uses a simpler approach and resets already if we have some
extra incoming edges.

2022-04-11  Jakub Jelinek  <jakub@redhat.com>

PR tree-optimization/105218
* tree-ssa-phiopt.cc (value_replacement): If middle_bb has
more than one predecessor or phi's bb more than 2 predecessors,
reset phi result uses instead of adding a debug temp.

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

libstdc++: Fix std::basic_stacktrace special members [PR105031]

The PR points out that there is a non-constant condition used for an
if-constexpr statement, but there are several other problems with the
copy, move and swap members of std::basic_stacktrace.

libstdc++-v3/ChangeLog:

PR libstdc++/105031
* include/std/stacktrace (basic_stacktrace::basic_stacktrace):
Fix allocator usage in constructors.
(basic_stacktrace::operator=(const basic_stacktrace&)): Do not
try to reallocate using const allocator.
(basic_stacktrace::operator=(basic_stacktrace&&)): Fix
if-constexpr with non-constant condition. Do not allocate new
storage if allocator propagates. Do not set _M_size if
allocation fails.
(basic_stacktrace::swap(basic_stacktrace&)): Fix typo. Add
assertion that non-propagating allocators are equal.
* testsuite/19_diagnostics/stacktrace/stacktrace.cc: New test.

libstdc++: Improve behaviour of std::stacktrace::current

This prevents inlining the current() function to guarantee that it is
present in the stacktrace, then tells libbacktrace to skip that frame.

To avoid overflow in the int argument to __glibcxx_backtrace_simple, we
need to check if the skip parameter exceeds INT_MAX (which is possible
for 16-bit targets where short and int have the same width). We also
need to limit the size of the returned value to the max_depth parameter,
which was missing previously.

This also fixes basic_stacktrace::max_size() to not exceed the maximum
size supported by the allocator, which might be smaller than the maximum
value of size_type.

libstdc++-v3/ChangeLog:

* include/std/stacktrace (basic_stacktrace::current): Duplicate
implementation into each overload. Add noinline attribute and
skip current frame.
(basic_stacktrace::max_size()): Call _Impl::_S_max_size.
(basic_stacktrace::_S_curr_cb()): New function defining lambda.
(basic_stacktrace::_Impl::_S_max_size): New function defining
maximum size in terms of allocator and size_type.
(basic_stacktrace::_Impl::_M_allocate): Check against
max_size().
* testsuite/19_diagnostics/stacktrace/entry.cc: Call function
for non-constexpr checks. Check line number is correct.

ppc: testsuite: require target effectively [PR104253]

The testcase was missing dg- before require-effective-target.

While at that, I'm also pruning the excess-error warning I got when
the test failed to be disabled because of the above.  I suppose it
might be useful for some target variants.

for gcc/testsuite/ChangeLog

PR target/104253
* gcc.target/powerpc/pr104253.c: Add missing dg- before
require-effective-target.  Prune warning about -mfloat128
possibly not being fully supported.

c++: Tolerate cdtors returning this in constexpr

On targets that return this from cdtors, cxx_eval_call_expression may
flag flowing off the end of a dtor.  That's preempted for ctors, and
avoided entirely when dtors return void, but when they return this,
the return value should be conceptually disregarded, without making
room for such internal ABI details to make a program ill-formed, as in
g++.dg/cpp2a/constexpr-dtor12.C on arm-eabi.

for  gcc/cp/ChangeLog

* constexpr.cc (cxx_eval_call_expression): Disregard dtor
result.

c++: Set loc on call even if result is discarded

This patch fixes a divergence in line numbers in diagnostics and,
presumably, debug information, between targets whose cdtors return
this and those that don't.

The problem was visible in g++.dg/cpp2a/constexpr-dtor3.C: while the
dtor call in the cleanup for f4 was expected at the closing brace, on
returning-this targets it came up at the assignment.

The reason is convoluted: statements in cleanups have their location
information removed, to avoid bumpy debugger behavior, and then set to
the location of the end of the scope.

The cleanup dtor call has its locus cleared in both kinds of targets,
but the end-of-scope locus doesn't make it on returning-this targets.
The calls are wrapped with a cast-to-void to discard the unused return
value, and the existing logic only attached the locus to the
conversion NOP_EXPR.

The call thus remains locus-less.  When constexpr logic copies and
evals the body, it sets unset locations; while copying cleanups, the
locus is taken from the cleanup expression, rather than matching the
end-of-scope locus set by the parser.  So we end up with different
locations.

This patch sets the locus of the call even when it's wrapped by a
convert-to-void NOP_EXPR, so it won't diverge any more.

for  gcc/cp/ChangeLog

* semantics.cc (set_cleanup_locs): Propagate locus to call
wrapped in cast-to-void.

RISC-V: Support -misa-spec for arch-canonicalize and multilib-generator. [PR104853]

We migrate the default ISA spec version from 2.2 to 20191213, but those scripts
aren't updated at the same time, this patch is making both scripts support
different ISA spec versions.

gcc/ChangeLog:

PR target/104853
* config.gcc: Pass -misa-spec to arch-canonicalize and
multilib-generator.
* config/riscv/arch-canonicalize: Adding -misa-spec option.
(SUPPORTED_ISA_SPEC): New.
(arch_canonicalize): New argument `isa_spec`.
Handle multiple ISA spec versions.
* config/riscv/multilib-generator: Adding -misa-spec option.

libstdc++: Move stacktrace tests to 19_diagnostics directory

This matches where the feature is defined in the current draft.

libstdc++-v3/ChangeLog:

* testsuite/20_util/stacktrace/entry.cc: Moved to...
* testsuite/19_diagnostics/stacktrace/entry.cc: ...here.
* testsuite/20_util/stacktrace/synopsis.cc: Moved to...
* testsuite/19_diagnostics/stacktrace/synopsis.cc: ...here.
* testsuite/20_util/stacktrace/version.cc: Moved to...
* testsuite/19_diagnostics/stacktrace/version.cc: ...here.

libstdc++: Move Filesystem TS path definitions out of class body

This fixes some errors with clang caused by instantiating vector<_Cmpt>
before the _Cmpt type is complete.

libstdc++-v3/ChangeLog:

* include/experimental/bits/fs_path.h (path): Define special
members after path::_Cmpt is complete.

RISC-V: Sync arch-canonicalize and riscv-common.cc

Currently we are sync that manually, but I guess we should re-implement
arch-canonicalize in C++, so that we could reuse the stuffs from
riscv-common.cc.

gcc/ChangeLog:

* config/riscv/arch-canonicalize: Add TODO item.
(IMPLIED_EXT): Sync.
(arch_canonicalize): Checking until no change.

middle-end: Prevent the use of the cond inversion detection code when both conditions are external. [PR105197]

Previously ifcvt used to enforce that a mask A and the inverse of said mask be
represented as ~A. So for the masks

  _25 = _6 != 0;
  _44 = _4 != 0;

ifcvt would produce for an operation requiring the inverse of said mask

  _26 = ~_25;
  _43 = ~_44;

but now that VN is applied to the entire function body we get a simplification
on the mask and produce:

  _26 = _6 == 0;
  _43 = _4 == 0;

This in itself is not a problem semantically speaking (though it does create
more masks that need to be tracked) but when vectorizing the masked conditional
we would still detect _26 and _43 to be inverses of _25 and _44 and mark them
as requiring their operands be swapped.

When vectorizing we swap the operands but don't find the BIT_NOT_EXPR to remove
and so we leave the condition as is which produces invalid code:

------>vectorizing statement: _ifc__41 = _43 ? 0 : _ifc__40;
created new init_stmt: vect_cst__136 = { 0, ... }
add new stmt: _137 = mask__43.26_135 & loop_mask_111
note:  add new stmt: vect__ifc__41.27_138 = VEC_COND_EXPR <_137, vect__ifc__40.25_133, vect_cst__136>;

This fixes disabling the inversion detection code when the loop isn't masked
since both conditional would be external.  We'd then not use the new cond_code
and would incorrectly still swap the operands.

The resulting code is also better than GCC-11 with most operations now
predicated on the loop mask rather than a ptrue.

gcc/ChangeLog:

PR target/105197
* tree-vect-stmts.cc (vectorizable_condition): Prevent cond swap when
not masked.

gcc/testsuite/ChangeLog:

PR target/105197
* gcc.target/aarch64/sve/pr105197-1.c: New test.
* gcc.target/aarch64/sve/pr105197-2.c: New test.

c++: -Wplacement-new and anon union member [PR100370]

This bug was an object/value confusion; we are interested in the size
of *b.ip, but instead the code was calculating the size of b.ip itself.

This seems to be because compute_objsize will compute the size of whatever
object it can find in the argument: if you pass it a VAR_DECL, it gives you
the size of that variable.  If you pass it an ADDR_EXPR of a VAR_DECL, it
again gives you the size of the variable.  The way you can tell the
difference is by looking at the deref member of access_ref: if it's -1, the
argument is a pointer to the object.  Since that's what we're interested in,
we should check for that, like check_dangling_stores does.

This regressed some tests because compute_objsize_r was wrongly zeroing
deref in the POINTER_PLUS_EXPR handling; adding an offset to a pointer
doesn't change whether the pointer is itself a variable or a pointer to
one.  In fact, handling POINTER_PLUS_EXPR only really makes sense for deref
== -1, where we're adjusting a pointer to the variable.

PR c++/100370

gcc/cp/ChangeLog:

* init.cc (warn_placement_new_too_small): Check deref.

gcc/ChangeLog:

* pointer-query.cc (compute_objsize_r) [POINTER_PLUS_EXPR]: Require
deref == -1.

gcc/testsuite/ChangeLog:

* g++.dg/warn/Wplacement-new-size-11.C: New test.

phiopt: Optimize (x != cst1 ? x : cst2) != cst3 [PR104639]

Here is an attempt to resolve a P1 regression, where due to threading
changes we no longer optimize
bool foo(int i) {
    while (i == 4)
        i += 2;
    return i;
}
to just return i != 0; by enhancing the phiopt value_replacement
optimization.  Normally it will optimize x != cst1 ? x : cst1 to x.
Here we extend it to also optimize x != cst1 ? x : cst2 to x if
it (phi result) has a single immediate use which is a comparison
with some INTEGER_CST cst3 and we can prove that we don't care
whether x is cst1 or cst2 because both compare the same against cst3.

2022-04-11  Jakub Jelinek  <jakub@redhat.com>

PR tree-optimization/104639
* tree-ssa-phiopt.cc: Include tree-ssa-propagate.h.
(value_replacement): Optimize (x != cst1 ? x : cst2) != cst3
into x != cst3.

* gcc.dg/tree-ssa/pr104639-1.c: New test.
* gcc.dg/tree-ssa/pr104639-2.c: New test.

c-family: Initialize ridpointers for __int128 etc. [PR105186]

The following testcase ICEs with C++ and is incorrectly rejected with C.
The reason is that both FEs use ridpointers identifiers for CPP_KEYWORD
and value or u.value for CPP_NAME e.g. when parsing attributes or OpenMP
directives etc., like:
         /* Save away the identifier that indicates which attribute
            this is.  */
         identifier = (token->type == CPP_KEYWORD)
           /* For keywords, use the canonical spelling, not the
              parsed identifier.  */
           ? ridpointers[(int) token->keyword]
           : id_token->u.value;

         identifier = canonicalize_attr_name (identifier);
I've tried to change those to use ridpointers only if non-NULL and otherwise
use the value/u.value even for CPP_KEYWORDS, but that was a large 10 hunks
patch.

The following patch instead just initializes ridpointers for the __intNN
keywords.  It can't be done earlier before we record_builtin_type as there
are 2 different spellings and if we initialize those ridpointers early, the
second record_builtin_type fails miserably.

2022-04-11  Jakub Jelinek  <jakub@redhat.com>

PR c++/105186
* c-common.cc (c_common_nodes_and_builtins): After registering __int%d
and __int%d__ builtin types, initialize corresponding ridpointers
entry.

* c-c++-common/pr105186.c: New test.

[committed] Minor bfin codegen bugfix

gcc/
* config/bfin/bfin.md (rol_one): Fix pattern to indicate the
sign bit of the source ends up in CC.

rs6000/test: Adjust p9-vec-length-{full,epil}-7.c [PR103196]

As PR103196 shows, complete unrolling pass still takes effect even
if we have specified the option "-fno-unroll-loops".  The loops in
that case are not expected to be transformed by it, otherwise the
expected counts change.  This patch is to add the disabling option
to make them not sensitive to complete unrolling.

PR testsuite/103196

gcc/testsuite/ChangeLog:

* gcc.target/powerpc/p9-vec-length-epil-7.c: Add option
-fdisable-tree-cunroll.
* gcc.target/powerpc/p9-vec-length-full-7.c: Likewise.

Daily bump.

Fortran: fix checking of coshape specification in ALLOCATE statement

gcc/fortran/ChangeLog:

PR fortran/105184
* array.cc (match_subscript): Reject assumed size coarray
specification with missing lower bound.
* resolve.cc (resolve_allocate_expr): Fix logic for checking
allocate-coshape-spec in ALLOCATE statement.

gcc/testsuite/ChangeLog:

PR fortran/105184
* gfortran.dg/coarray_44.f90: Adjust expected output.
* gfortran.dg/coarray_allocate_11.f90: Likewise.
* gfortran.dg/coarray_allocate_12.f90: New test.

Daily bump.

analyzer: fix folding of regions involving unknown ptrs [PR103892]

PR analyzer/103892 reports a false positive from -Wanalyzer-double-free.

The root cause is the analyzer failing to properly handle "unknown"
symbolic regions, and thus confusing two different expressions.

Specifically, the analyzer eventually hits the complexity limit for
symbolic values, and starts using an "unknown" svalue for a pointer.
The analyzer uses
  symbolic_region(unknown_svalue([of ptr type]))
i.e.
  (*UNKNOWN_PTR)
in a few places to mean "we have an lvalue, but we're not going to
attempt to track what it is anymore".

"Unknown" should probably be renamed to "unknowable"; in theory, any
operation on such an unknown svalue should be also an unknown svalue.

The issue is that in various places where we create child regions, we
were failing to check for the parent region being (*UNKNOWN_PTR), and so
were erroneously creating regions based on (*UNKNOWN_PTR), such as
*(UNKNOWN_PTR + OFFSET).  The state-machine handling was erroneously
allowing e.g. INITIAL_VALUE (*(UNKNOWN_PTR + OFFSET)) to have state,
and thus we could record that such a value had had "free" called on it,
and thus eventually false report a double-free when a different
expression incorrectly "simplified" to the same expression.

This patch fixes things by checking when creating the various kinds of
child region for (*UNKNOWN_PTR) as the parent region, and simply
returning another (*UNKNOWN_PTR) for such child regions (using the
appropriate type).

Doing so fixes the false positive, and also fixes a state explosion on
this testcase, as the states at the program points more rapidly reach
a fixed point where everything is unknown.  I checked for other cases
that no longer needed -Wno-analyzer-too-complex; the only other one
seems to be gcc.dg/analyzer/pr96841.c, but that seems to already have
become redundant at some point before this patch.

gcc/analyzer/ChangeLog:
PR analyzer/103892
* region-model-manager.cc
(region_model_manager::get_unknown_symbolic_region): New,
extracted from...
(region_model_manager::get_field_region): ...here.
(region_model_manager::get_element_region): Use it here.
(region_model_manager::get_offset_region): Likewise.
(region_model_manager::get_sized_region): Likewise.
(region_model_manager::get_cast_region): Likewise.
(region_model_manager::get_bit_range): Likewise.
* region-model.h
(region_model_manager::get_unknown_symbolic_region): New decl.
* region.cc (symbolic_region::symbolic_region): Handle sval_ptr
having NULL type.
(symbolic_region::dump_to_pp): Handle having NULL type.

gcc/testsuite/ChangeLog:
PR analyzer/103892
* gcc.dg/analyzer/pr103892.c: New test.
* gcc.dg/analyzer/pr96841.c: Drop redundant
-Wno-analyzer-too-complex.

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

Update semantic_interposition flag at analysis time

This patch solves problem with FE first finalizing function and then adding
-fno-semantic-interposition flag (by parsing optimization attribute).

gcc/ChangeLog:

2022-04-09  Jan Hubicka  <hubicka@ucw.cz>

PR ipa/103376
* cgraphunit.cc (cgraph_node::analyze): update semantic_interposition
flag.

gcc/testsuite/ChangeLog:

2022-04-09  Jan Hubicka  <hubicka@ucw.cz>

PR ipa/103376
* gcc.c-torture/compile/pr103376.c: New test.

Propagate nondeterministic and side_effects flags in modref summary after inlining

gcc/ChangeLog:

2022-04-09  Jan Hubicka  <hubicka@ucw.cz>

* ipa-modref.cc (ipa_merge_modref_summary_after_inlining): Propagate
nondeterministic and side_effects flags.

gcc/testsuite/ChangeLog:

2022-04-09  Jan Hubicka  <hubicka@ucw.cz>

* gcc.dg/ipa/pr105160.c: New test.

loongarch: testsuite: adapt stack-usage-1.c for LP64

LoongArch backend allocates two additional 8-byte stack slots for LP64,
one for saving $fp and another for saving the temporary value "1".
Ideally they are both unneeded, but (1) we're using -O0 so the code is
suboptimized by the nature; (2) any improvement (if possible) should be
deferred to GCC 13.  So for now simply adjust the test to make it pass.

gcc/testsuite/

* gcc.dg/stack-usage-1.c: Adjust for LoongArch LP64.

loongarch: testsuite: skip builtin-apply2.c

On LoongArch, variadic functions use different arugment passing
conventions so this test is not valid (see the section named "Variadic
argument" in the [ELF ABI][1]) and should be skipped.

[1]: https://loongson.github.io/LoongArch-Documentation/LoongArch-ELF-ABI-EN.html

gcc/testsuite/

* gcc.dg/builtin-apply2.c (dg-skip-if): Add loongarch*-*-*.

c++: constexpr non-trivial aggregate init [PR105191]

My patch for PR92385 made us use VEC_INIT_EXPR for aggregate initialization
of an array where some elements are not explicitly initialized.  Constexpr
handling of that was treating initialization from {} as equivalent to
value-initialization, which is problematic for classes with default member
initializers that make the default constructor non-trivial; in older
standard modes, not initializing all members makes a constructor
non-constexpr, but aggregate initialization is fine.

PR c++/105191
PR c++/92385

gcc/cp/ChangeLog:

* tree.cc (build_vec_init_elt): Do {}-init for aggregates.
* constexpr.cc (cxx_eval_vec_init): Only treat {} as value-init
for non-aggregate types.
(build_vec_init_expr): Also check constancy of explicit
initializer elements.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/constexpr-array28.C: New test.

c++: friend implicit template instantiation [PR91618]

This rule that for a friend with a qualified name we try to find a
matching template was already in C++98, but it seems we never implemented
it, and nobody reported it until 2019.

This patch sets DECL_IMPLICIT_INSTANTIATION to signal to
check_explicit_specialization that we want to find a template, like
grokfndecl already did for explicit template args.  check_classfn also needs
to call it, as check_classfn is called after the call to
check_explicit_specialization in grokfndecl, whereas the call to
set_decl_namespace comes sooner.  This inconsistency is inelegant, but safer
at this point in the release cycle; I'll unify them in stage 1.

PR c++/91618
PR c++/96604

gcc/cp/ChangeLog:

* name-lookup.cc (set_decl_namespace): Set
DECL_IMPLICIT_INSTANTIATION if no non-template match.
* pt.cc (check_explicit_specialization): Check it.
* decl2.cc (check_classfn): Call it.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/friend7.C: Remove xfail.
* g++.dg/template/friend72.C: New test.
* g++.dg/template/friend72a.C: New test.
* g++.dg/template/friend73.C: New test.

Daily bump.

libstdc++: Fix constraints on std::expected<void, E> constructor [PR105153]

libstdc++-v3/ChangeLog:

PR libstdc++/105153
* include/std/expected
(expected<void,E>::expected(expected<U,G>&&)): Fix constraints.
* testsuite/20_util/expected/cons.cc: Check constructor.

libstdc++: Fix std::expected<void, E>::swap(expected&) [PR105154]

libstdc++-v3/ChangeLog:

PR libstdc++/105154
* include/std/expected (expected<void, E>::swap): Set
_M_has_value to false for objects that previously had a value.
* testsuite/20_util/expected/swap.cc: Fix test to check void
specialization.

libstdc++: Fix std::bad_expected_access constructor [PR105146]

libstdc++-v3/ChangeLog:

PR libstdc++/105146
* include/std/expected (bad_expected_access): Move constructor
parameter.
* testsuite/20_util/expected/bad.cc: New test.

aarch64: PR target/105157 Increase number of cores TARGET_CPU_DEFAULT can encode

This addresses the compile-time increase seen in the PR target/105157. This was
being caused by selecting the wrong core tuning, as when we added the latest
AArch64 the TARGET_CPU_generic tuning was pushed beyond the 0x3f mask we used
to encode both target cpu and attributes into TARGET_CPU_DEFAULT.

gcc/ChangeLog:

PR target/105157
* config.gcc: Shift ext_mask by TARGET_CPU_NBITS.
* config/aarch64/aarch64.h (TARGET_CPU_NBITS): New macro.
(TARGET_CPU_MASK): Likewise.
(TARGET_CPU_DEFAULT): Use TARGET_CPU_NBITS.
* config/aarch64/aarch64.cc (aarch64_get_tune_cpu): Use TARGET_CPU_MASK.
(aarch64_get_arch): Likewise.
(aarch64_override_options): Use TARGET_CPU_NBITS.

tree-optimization/105198 - wrong code with predictive commoning

When predictive commoning looks for a looparound PHI it tries
to match the entry value definition (a load) up with the appropriate
member of the chain.  But it fails to consider stmts clobbering
the very same memory location inbetween the load and loop entry.

In theory we could be more clever on must aliases that would be
also picked up from a load (so not exactly stmt_kills_ref_p) and
use the stored value from that if it is an exact match.  But we
currently have no way to propagate this information inside predcom.

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

PR tree-optimization/105198
* tree-predcom.cc (find_looparound_phi): Check whether
the found memory location of the entry value is clobbered
inbetween the value we want to use and loop entry.

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

testsuite: Fix up 20050113-1.c test for i686-linux [PR105187]

The test FAILs on i686-linux if neither MMX isn't enabled, can be also
reproduced with
make check-gcc check-g++ RUNTESTFLAGS='--target_board=unix/-m32/-mno-mmx/-mno-sse dg-torture.exp=20050113-1.c'
on x86_64-linux.  Previously the test was in gcc.c-torture/compile/
where -w is added by default.

2022-04-08  Jakub Jelinek  <jakub@redhat.com>

PR c++/105187
* c-c++-common/torture/20050113-1.c: Add dg-additional-options
-Wno-psabi.

c: Error on va_arg with function type [PR105149]

In the PR Joseph said that the C standard for va_arg talks about
pointers to object type and as a function type is not object type,
it is invalid.

The following patch diagnoses it in the FE, instead of ICEing later on
when optimizations are turned on (and with -O0 doing something weird
at runtime).

2022-04-08  Jakub Jelinek  <jakub@redhat.com>

PR c/105149
* c-typeck.cc (c_build_va_arg): Reject function types.

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

fold-const: Fix up make_range_step [PR105189]

The following testcase is miscompiled, because fold_truth_andor
incorrectly folds
(unsigned) foo () >= 0U && 1
into
foo () >= 0
For the unsigned comparison (which is useless in this case,
as >= 0U is always true, but hasn't been folded yet), previous
make_range_step derives exp (unsigned) foo () and +[0U, -]
range for it.  Next we process the NOP_EXPR.  We have special code
for unsigned to signed casts, already earlier punt if low or high
aren't representable in arg0_type or if it is a narrowing conversion.
For the signed to unsigned casts, I think if high is specified we
are still fine, as we punt for non-representable values in arg0_type,
n_high is then still representable and so was smaller or equal to
signed maximum and either low is not present (equivalent to 0U), or
low must be smaller or equal to high and so for unsigned exp
+[low, high] the signed exp +[n_low, n_high] will be correct.
Similarly, if both low and high aren't specified (always true or
always false), it is ok too.
But if we have for unsigned exp +[low, -] or -[low, -], using
+[n_low, -] or -[n_high, -] is incorrect.  Because low is smaller
or equal to signed maximum and high is unspecified (i.e. unsigned
maximum), when signed that range is a union of +[n_low, -] and
+[-, -1] which is equivalent to -[0, n_low-1], unless low
is 0, in that case we can treat it as [-, -].

2022-04-08  Jakub Jelinek  <jakub@redhat.com>

PR tree-optimization/105189
* fold-const.cc (make_range_step): Fix up handling of
(unsigned) x +[low, -] ranges for signed x if low fits into
typeof (x).

* g++.dg/torture/pr105189.C: New test.

libgcc: IA64: don't compile glibc-based unwinder without libc headers

In --without-headers mode gcc fails to bootstrap on libgcc as:

    /build/build/./gcc/xgcc -B/build/build/./gcc/ ... -Dinhibit_libc -c fde-glibc.c
    ../../../gcc-12-20220403/libgcc/config/ia64/fde-glibc.c:33:10:
        fatal error: stdlib.h: No such file or directory

Most other linux targets are able to build the --without-headers
compiler without additional effort. This change adds IA64 to the fold.

The change drops part of the code that relies on DYNAMIC glibc
section traversal for backtraces.

Tested bootstrap of ia64-unknown-linux-gnu with and without libc
headers present.

libgcc/
* config/ia64/fde-glibc.c: Make a no-op in inhibit_libc mode.

tree-optimization/105175 - avoid -Wvector-operation-performance

This avoids -Wvector-operation-performance diagnostics for vectorizer
produced code.  It's unfortunate the warning_at code in
tree-vect-generic.cc needs adjustments but the diagnostic suppression
code doesn't magically suppress those otherwise.

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

PR tree-optimization/105175
* tree-vect-stmts.cc (vectorizable_operation): Suppress
-Wvector-operation-performance if using emulated vectors.
* tree-vect-generic.cc (expand_vector_piecewise): Do not diagnose
-Wvector-operation-performance when suppressed.
(expand_vector_parallel): Likewise.
(expand_vector_comparison): Likewise.
(expand_vector_condition): Likewise.
(lower_vec_perm): Likewise.
(expand_vector_conversion): Likewise.

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

Daily bump.

Disable float128 tests on VxWorks, PR target/104253.

In PR target/104253, it was pointed out the that test case added as part
of fixing the PR does not work on VxWorks because float128 is not
supported on that system.  I have modified the three tests for float128 so
that they are manually excluded on VxWorks systems.  In looking at the
code, I also added checks in check_effective_target_ppc_ieee128_ok to
disable the systems that will never support VSX instructions which are
required for float128 support (eabi, eabispe, darwin).

2022-04-07   Michael Meissner  <meissner@linux.ibm.com>

gcc/testsuite/
PR target/104253
* lib/target-supports.exp (check_ppc_float128_sw_available): Do
not run float128 tests on VxWorks.
(check_ppc_float128_hw_available): Likewise.
(check_effective_target_ppc_ieee128_ok): Likewise.

c++: use after free during name lookup w/ modules [PR99479]

name_lookup::search_unqualified uses a statically allocated vector
in order to avoid repeated reallocation, under the assumption that
the function can't be called recursively.  With modules however,
this assumption turns out to be false, and search_unqualified can
be called recursively as demonstrated by the testcase in comment #19
of PR99479[1] where the recursive call causes the vector to get
reallocated which invalidates the reference to queue[ix] held by the
parent call.

This patch makes search_unqualified instead use an auto_vec with 16
elements of internal storage.  In turn we can simplify the API of some
member functions to take the vector by reference and return void.

[1]: https://gcc.gnu.org/PR99479#c19

PR c++/99479

gcc/cp/ChangeLog:

* name-lookup.cc (name_lookup::using_queue): Change to an
auto_vec (with 16 elements of internal storage).
(name_lookup::queue_namespace): Change return type to void,
take queue parameter by reference and adjust function body
accordingly.
(name_lookup::do_queue_usings): Inline into ...
(name_lookup::queue_usings): ... here.  As in queue_namespace.
(name_lookup::search_unqualified): Don't make queue static,
remove length variable, and adjust function body accordingly.

testsuite: delete slp scan from loop vect test.

I accidentally left in an slp1 check in the vect test which showed up as
UNRESOLVED and had missed it in the sum file.  This deletes that line.

gcc/testsuite/ChangeLog:

PR testsuite/105196
* gcc.dg/vect/complex/fast-math-complex-add-pattern-float.c: Remove slp1 check.

AArch64: fix ls64 intrinsics expansion [PR104409]

The LS64 intrinsics used a machinery that's not safe to use unless being
called from a pragma instantiation.

This moves the initialization code to a new pragma for arm_acle.h.

gcc/ChangeLog:

PR target/104409
* config/aarch64/aarch64-builtins.cc (handle_arm_acle_h): New.
(aarch64_general_init_builtins): Move LS64 code.
* config/aarch64/aarch64-c.cc (aarch64_pragma_aarch64): Support
arm_acle.h
* config/aarch64/aarch64-protos.h (handle_arm_acle_h): New.
* config/aarch64/arm_acle.h: Add pragma GCC aarch64 "arm_acle.h".

ipa/104303 - miscompilation of gnatmake

Modref attempts to track memory accesses relative to the base pointers
which are parameters of functions.
If it fails, it still makes difference between unknown memory access and
global memory access.  The second makes it possible to disambiguate with
memory that is not accessible from outside world (i.e. everything that does
not escape from the caller function).  This is useful so we do not punt
when unknown function is called.

The added ref_may_access_global_memory_p ends up using
ptr_deref_may_alias_global_p which does not consider escaped automatic
variables as global.  For modref those are still global since they
can be accessed from functions called.

The following adds a flag to the *_global_p APIs indicating whether
escaped local memory should be considered as global or not and
removes ref_may_access_global_memory_p in favor of using
ref_may_alias_global_p with the flag set to true.

2022-04-07  Richard Biener  <rguenther@suse.de>
    Jan Hubicka  <hubicka@ucw.cz>

PR ipa/104303
* tree-ssa-alias.h (ptr_deref_may_alias_global_p,
ref_may_alias_global_p, ref_may_alias_global_p,
stmt_may_clobber_global_p, pt_solution_includes_global): Add
bool parameters indicating whether escaped locals should be
considered global.
* tree-ssa-structalias.cc (pt_solution_includes_global):
When the new escaped_nonlocal_p flag is true also consider
pt->vars_contains_escaped.
* tree-ssa-alias.cc (ptr_deref_may_alias_global_p):
Pass down new escaped_nonlocal_p flag.
(ref_may_alias_global_p): Likewise.
(stmt_may_clobber_global_p): Likewise.
(ref_may_alias_global_p_1): Likewise.  For decls also
query the escaped solution if true.
(ref_may_access_global_memory_p): Remove.
(modref_may_conflict): Use ref_may_alias_global_p with
escaped locals considered global.
(ref_maybe_used_by_stmt_p): Adjust.
* ipa-fnsummary.cc (points_to_local_or_readonly_memory_p):
Likewise.
* tree-ssa-dse.cc (dse_classify_store): Likewise.
* trans-mem.cc (thread_private_new_memory): Likewise, but
consider escaped locals global.
* tree-ssa-dce.cc (mark_stmt_if_obviously_necessary): Likewise.

* gnat.dg/concat5.adb: New.
* gnat.dg/concat5_pkg1.adb: Likewise.
* gnat.dg/concat5_pkg1.ads: Likewise.
* gnat.dg/concat5_pkg2.adb: Likewise.
* gnat.dg/concat5_pkg2.ads: Likewise.

analyzer: fix leak false +ve with symbolic writes [PR102208]

PR analyzer/102208 reports false positives from -Wanalyzer-malloc-leak.
The root cause is the analyzer getting confused about symbolic writes
that could alias a pointer referencing a malloced buffer.

struct st
{
  void *ptr;
  int arr[10];
};

struct st test (int idx)
{
  struct st s;
  s.ptr = __builtin_malloc (1024);  /* (1) */
  s.arr[idx] = 42;                  /* (2) */
  return s;
}

When removing overlapping bindings at (2),
store::remove_overlapping_bindings was failing to pass on the
uncertainty_t *, and thus when clobbering the binding of s.ptr, the
heap-allocated pointer was not being added to the set of maybe-bound
svalues, and thus being treated as leaking.

This patch fixes this, so that s.ptr from (1) is treated as maybe-bound
after the write at (2), fixing the leak false postive.

Doing so requires the store to be smarter about how clobbering happens
with various combinations of concrete keys and symbolic keys within
concrete clusters and symbolic clusters, so that we don't lose warnings
about definite leaks.

gcc/analyzer/ChangeLog:
PR analyzer/102208
* store.cc (binding_map::remove_overlapping_bindings): Add
"always_overlap" param, using it to generalize to the case where
we want to remove all bindings.  Update "uncertainty" logic to
only record maybe-bound values for cases where there is a symbolic
write involved.
(binding_cluster::mark_region_as_unknown): Split param "reg" into
"reg_to_bind" and "reg_for_overlap".
(binding_cluster::maybe_get_compound_binding): Pass "false" to
binding_map::remove_overlapping_bindings new "always_overlap" param.
(binding_cluster::remove_overlapping_bindings): Determine
"always_overlap" and pass it to
binding_map::remove_overlapping_bindings.
(store::set_value): Pass uncertainty to remove_overlapping_bindings
call.  Update for new param of
binding_cluster::mark_region_as_unknown, passing both the base
region of the iter_cluster, and the lhs_reg.
(store::mark_region_as_unknown): Update for new param of
binding_cluster::mark_region_as_unknown, passing "reg" for both.
(store::remove_overlapping_bindings): Add param "uncertainty", and
pass it on to call to
binding_cluster::remove_overlapping_bindings.
* store.h (binding_map::remove_overlapping_bindings): Add
"always_overlap" param.
(binding_cluster::mark_region_as_unknown): Split param "reg" into
"reg_to_bind" and "reg_for_overlap".
(store::remove_overlapping_bindings): Add param "uncertainty".

gcc/testsuite/ChangeLog:
PR analyzer/102208
* gcc.dg/analyzer/symbolic-9.c: New test.
* gcc.dg/analyzer/torture/leak-pr102308-1.c: New test.
* gcc.dg/analyzer/torture/leak-pr102308-2.c: New test.

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

tree-optimization/105185 - simplify modref query in SCCVN

This simplifies the modref query for calls in SCCVN again after
r12-8019-g4be08315124281, avoiding an ICE when the modref
analyzed access lacks an actual argument on the caller side.
It effectively reverts r12-7531-gdc46350d44c294.

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

PR tree-optimization/105185
* tree-ssa-sccvn.cc (visit_reference_op_call): Simplify
modref query again.

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

AArch64: Fix left fold sum reduction RTL patterns [PR104049]

As the discussion in the PR pointed out the RTL we have for the REDUC_PLUS
patterns are wrong.  The UNSPECs are modelled as returning a vector and then
in an expand pattern we emit a vec_select of the 0th element to get the scalar.

This is incorrect as the instruction itself already only returns a single scalar
and by declaring it returns a vector it allows combine to push in a subreg into
the pattern, which causes reload to make duplicate moves.

This patch corrects this by removing the weird indirection and making the RTL
pattern model the correct semantics of the instruction immediately.

gcc/ChangeLog:

PR target/104049
* config/aarch64/aarch64-simd.md
(aarch64_reduc_plus_internal<mode>): Fix RTL and rename to...
(reduc_plus_scal_<mode>): ... This.
(reduc_plus_scal_v4sf): Moved.
(aarch64_reduc_plus_internalv2si): Fix RTL and rename to...
(reduc_plus_scal_v2si): ... This.

gcc/testsuite/ChangeLog:

PR target/104049
* gcc.target/aarch64/vadd_reduc-1.c: New test.
* gcc.target/aarch64/vadd_reduc-2.c: New test.

testsuite: enable fast-math-complex-* testcases.

As pointed out in PR105095 these tests weren't running, mainly because the .exp
file contains a filter on the first character so it can distinguish between
fast-math-bb-slp-* and fast-math-*, my test started with `c` and so didn't get
found.

This patch adds `c` to the list of filters and also updates the output and
required guards for the testcases now that they run.

gcc/testsuite/ChangeLog:

PR testsuite/105095
* gcc.dg/vect/complex/fast-math-complex-add-double.c: Update for codegen.
* gcc.dg/vect/complex/fast-math-complex-add-float.c: Likewise.
* gcc.dg/vect/complex/fast-math-complex-add-half-float.c: Likewise.
* gcc.dg/vect/complex/fast-math-complex-add-pattern-double.c: Likewise.
* gcc.dg/vect/complex/fast-math-complex-add-pattern-float.c: Likewise.
* gcc.dg/vect/complex/fast-math-complex-add-pattern-half-float.c: Likewise.
* gcc.dg/vect/complex/fast-math-complex-mla-half-float.c: Likewise.
* gcc.dg/vect/complex/fast-math-complex-mls-double.c: Likewise.
* gcc.dg/vect/complex/fast-math-complex-mls-float.c: Likewise.
* gcc.dg/vect/complex/fast-math-complex-mls-half-float.c: Likewise.
* gcc.dg/vect/complex/fast-math-complex-mul-double.c: Likewise.
* gcc.dg/vect/complex/fast-math-complex-mul-float.c: Likewise.
* gcc.dg/vect/complex/fast-math-complex-mul-half-float.c: Likewise.
* gcc.dg/vect/vect.exp: Add extra letter to filter.

testsuite: skip PR103350 tests on big-endian

These tests are reduced from a C program and use gcc vector extensions and so
aren't endianness agnostic. As such skip them on BE.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/pr103350-1.c: Skip on BE.
* gcc.target/aarch64/pr103350-2.c: Likewise.

c++: Handle __builtin_clear_padding on non-trivially-copyable types [PR102586]

On Fri, Feb 11, 2022 at 07:55:50PM +0100, Jakub Jelinek via Gcc-patches wrote:
> Something like the https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102586#c16
> will still be needed with adjusted testcase from
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102586#c15 such that
> __builtin_clear_padding is called directly on var addresses rather than
> in separate functions.

Here is an updated version of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102586#c15
patch which uses FIELD_DECL in the langhook instead of its TREE_TYPE,
and the testcases have been adjusted for the builtin accepting
pointers to non-trivially-copyable types only if it is address of a
declaration.

2022-04-07  Jakub Jelinek  <jakub@redhat.com>

PR tree-optimization/102586
gcc/
* langhooks.h (struct lang_hooks_for_types): Add classtype_as_base
langhook.
* langhooks-def.h (LANG_HOOKS_CLASSTYPE_AS_BASE): Define.
(LANG_HOOKS_FOR_TYPES_INITIALIZER): Add it.
* gimple-fold.cc (clear_padding_type): Use ftype instead of
TREE_TYPE (field) some more.  For artificial FIELD_DECLs without
name try the lang_hooks.types.classtype_as_base langhook and
if it returns non-NULL, use that instead of ftype for recursive call.
gcc/cp/
* cp-objcp-common.h (cp_classtype_as_base): Declare.
(LANG_HOOKS_CLASSTYPE_AS_BASE): Redefine.
* cp-objcp-common.cc (cp_classtype_as_base): New function.
gcc/testsuite/
* g++.dg/torture/builtin-clear-padding-5.C: New test.
* g++.dg/cpp2a/builtin-clear-padding1.C (bar): Uncomment one
call that is now accepted.

tree.cc: Add tree_builtin_call_types_compatible_p [PR105150]

And here is the follow-up patch that does the argument checking
on GENERIC.  It ensures TYPE_MAIN_VARIANT == TYPE_MAIN_VARIANT
compatibility on the arguments, except for pointer arguments
where both builtin's prototype and actual arguments have to be
pointers and satisfy tree_nop_conversion_p, and for promoted
char/short arguments where argument need to have integral
signed type tree_nop_conversion_p compatible with integer_type_node.

2022-04-07  Jakub Jelinek  <jakub@redhat.com>

PR tree-optimization/105150
* tree.cc (tree_builtin_call_types_compatible_p): New function.
(get_call_combined_fn): Use it.

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

middle-end/105165 - sorry instead of ICE for _Complex asm goto

Complex lowering cannot currently deal with asm gotos with _Complex
output operands.  Emit a sorry instead of ICEing, those should not
appear in practice.

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

PR middle-end/105165
* tree-complex.cc (expand_complex_asm): Sorry for asm goto
_Complex outputs.

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

IBM zSystems/testsuite: PR105147: Skip pr105140.c

pr105140.c fails on IBM zSystems with "vector argument passed to
unprototyped function".  s390_invalid_arg_for_unprototyped_fn in
s390.cc is triggered by that.

gcc/testsuite/ChangeLog:

PR target/105147
* gcc.dg/pr105140.c: Skip for s390*-*-*.

Refine and/ior/xor/andn masked patterns for V*HFmode.

There's no masked vpandw or vpandb, similar for vpxor/vpor/vpandn.

gcc/ChangeLog:

* config/i386/sse.md (<sse2_avx2>_andnot<mode>3_mask):
Removed.
(<sse>_andnot<mode>3<mask_name>): Disable V*HFmode patterns
for mask_applied.
(<code><mode>3<mask_name>): Ditto.
(*<code><mode>3<mask_name>): Ditto.
(VFB_128_256): Adjust condition of V8HF/V16HFmode according to
real instruction.
(VFB_512): Ditto.
(VFB): Ditto.

c++: conversion with trailing return type [PR101051]

We've had a diagnostic for this, but since r10-6571 added an assert to
splice_late_return_type, we need to diagnose before we call it.

PR c++/101051

gcc/cp/ChangeLog:

* decl.cc (grokdeclarator): Reject conversion with trailing return
sooner.

gcc/testsuite/ChangeLog:

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

c++: nested generic lambda in DMI [PR101717]

We were already checking COMPLETE_TYPE_P to recognize instantiation of a
generic lambda, but didn't consider that we might be nested in a non-generic
lambda.

PR c++/101717

gcc/cp/ChangeLog:

* lambda.cc (lambda_expr_this_capture): Check all enclosing
lambdas for completeness.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1y/lambda-generic-this4.C: New test.

libstdc++-v3 expected: Correct minimal-size test in requirements.cc

Without this, for a target where alignment and structure-sizes are by
default byte-aligned, such as cris-elf, you'll see, in libstdc++.log:

/X/gcc/libstdc++-v3/testsuite/20_util/expected/requirements.cc:127: error: static assertion failed
/X/gcc/libstdc++-v3/testsuite/20_util/expected/requirements.cc:127: note: the comparison reduces to '(5 == 2)'
compiler exited with status 1
FAIL: 20_util/expected/requirements.cc (test for excess errors)
Excess errors:
/X/gcc/libstdc++-v3/testsuite/20_util/expected/requirements.cc:127: error: static assertion failed

The intent of that line is to check that the object is not larger than
necessary.

libstdc++-v3/:
* testsuite/20_util/expected/requirements.cc: Correct minimal-size
test.

c++: vector compound literal [PR105187]

My cleanup in r12-296 cleared TREE_HAS_CONSTRUCTOR on digested class
initializers, but we leave it set for vectors, since we can't wrap them in
TARGET_EXPR.

PR c++/105187

gcc/cp/ChangeLog:

* typeck2.cc (store_init_value): Allow TREE_HAS_CONSTRUCTOR for
vectors.

gcc/testsuite/ChangeLog:

* gcc.c-torture/compile/20050113-1.c: Moved to...
* c-c++-common/torture/20050113-1.c: ...here.

Daily bump.

Move 'libgomp/plugin/cuda/cuda.h' to 'include/cuda/cuda.h'

... so that it may be used by other projects that inherit GCC's 'include'
directory.

include/
* cuda/cuda.h: New file.
libgomp/
* plugin/cuda/cuda.h: Remove file.
* plugin/plugin-nvptx.c [PLUGIN_NVPTX_DYNAMIC]: Include
"cuda/cuda.h" instead of <cuda.h>.
* plugin/configfrag.ac <PLUGIN_NVPTX_DYNAMIC>: Don't set
'PLUGIN_NVPTX_CPPFLAGS'.
* configure: Regenerate.

jit: fix location of .png files for "make jit.pdf" [PR102824]

"make jit.pdf" seems to be looking in
  gcc/jit/docs/_build/texinfo/libgccjit-figures
for the .png files, but they were in the source tree in:
  gcc/jit/docs/_build/texinfo

Fix "make jit.pdf" via:
  git mv \
    gcc/jit/docs/_build/texinfo/*.png \
    gcc/jit/docs/_build/texinfo/libgccjit-figures

gcc/jit/ChangeLog:
PR jit/102824
* docs/_build/texinfo/factorial.png: Move to...
* docs/_build/texinfo/libgccjit-figures/factorial.png: ...here.
* docs/_build/texinfo/factorial1.png: Move to...
* docs/_build/texinfo/libgccjit-figures/factorial1.png: ...here.
* docs/_build/texinfo/sum-of-squares.png: Move to...
* docs/_build/texinfo/libgccjit-figures/sum-of-squares.png: ...here.
* docs/_build/texinfo/sum-of-squares1.png: Move to...
* docs/_build/texinfo/libgccjit-figures/sum-of-squares1.png: ...here.

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

combine: Don't record for UNDO_MODE pointers into regno_reg_rtx array [PR104985]

The testcase in the PR fails under valgrind on mips64 (but only Martin
can reproduce, I couldn't).
But the problem reported there is that SUBST_MODE remembers addresses
into the regno_reg_rtx array, then some splitter needs a new pseudo
and calls gen_reg_rtx, which reallocates the regno_reg_rtx array
and finally undo operation is done and dereferences the old regno_reg_rtx
entry.
The rtx values stored in regno_reg_rtx array seems to be created
by gen_reg_rtx only and since then aren't modified, all we do for it
is adjusting its fields (e.g. adjust_reg_mode that SUBST_MODE does).

So, I think it is useless to use where.r for UNDO_MODE and store
&regno_reg_rtx[regno] in struct undo, we can store just
regno_reg_rtx[regno] (i.e. pointer to the REG itself instead of
pointer to pointer to REG) or could also store just the regno.

The following patch does the latter, and because SUBST_MODE no longer
needs to be a macro, changes all SUBST_MODE uses to subst_mode.

2022-04-06  Jakub Jelinek  <jakub@redhat.com>

PR rtl-optimization/104985
* combine.cc (struct undo): Add where.regno member.
(do_SUBST_MODE): Rename to ...
(subst_mode): ... this.  Change first argument from rtx * into int,
operate on regno_reg_rtx[regno] and save regno into where.regno.
(SUBST_MODE): Remove.
(try_combine): Use subst_mode instead of SUBST_MODE, change first
argument from regno_reg_rtx[whatever] to whatever.  For UNDO_MODE, use
regno_reg_rtx[undo->where.regno] instead of *undo->where.r.
(undo_to_marker): For UNDO_MODE, use regno_reg_rtx[undo->where.regno]
instead of *undo->where.r.
(simplify_set): Use subst_mode instead of SUBST_MODE, change first
argument from regno_reg_rtx[whatever] to whatever.

c++: Fix up ICE when cplus_decl_attributes is called with error_mark_node attributes [PR104668]

cplus_decl_attributes can be called with attributes equal to
error_mark_node, there are some spots in the function that test
it or decl_attributes it calls starts with:
  if (TREE_TYPE (*node) == error_mark_node || attributes == error_mark_node)
    return NULL_TREE;
But the recent PR104245 change broke this when processing_template_decl
is true.

The patch returns early for attributes error_mark_node from
cplus_decl_attributes.

2022-04-06  Jakub Jelinek  <jakub@redhat.com>

PR c++/104668
* decl2.cc (splice_template_attributes): Return NULL if *p is
error_mark_node.
(cplus_decl_attributes): Return early if attributes is
error_mark_node.  Don't check that later.

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

c++: make -Wctad-maybe-unsupported respect complain [PR105143]

We were attempting to issue a -Wctad-maybe-unsupported warning even when
complain=tf_none, which led to a crash in the first testcase below and a
bogus error during overload resolution in the second testcase.

PR c++/105143

gcc/cp/ChangeLog:

* pt.cc (do_class_deduction): Check complain before attempting
to issue a -Wctad-maybe-unsupported warning.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/nodiscard1.C: New test.
* g++.dg/warn/Wctad-maybe-unsupported4.C: New test.

sh: Fix up __attribute__((optimize ("Os"))) handling on SH [PR105069]

As mentioned in the PR, various tests on sh-elf ICE like:
make check-gcc RUNTESTFLAGS="compile.exp='pr104327.c pr58332.c pr81360.c pr84425.c'"
FAIL: gcc.c-torture/compile/pr104327.c   -O0  (internal compiler error: 'global_options' are modified in local context)
FAIL: gcc.c-torture/compile/pr104327.c   -O0  (test for excess errors)
FAIL: gcc.c-torture/compile/pr104327.c   -O1  (internal compiler error: 'global_options' are modified in local context)
FAIL: gcc.c-torture/compile/pr104327.c   -O1  (test for excess errors)
FAIL: gcc.c-torture/compile/pr104327.c   -O2  (internal compiler error: 'global_options' are modified in local context)
FAIL: gcc.c-torture/compile/pr104327.c   -O2  (test for excess errors)
FAIL: gcc.c-torture/compile/pr104327.c   -O3 -g  (internal compiler error: 'global_options' are modified in local context)
FAIL: gcc.c-torture/compile/pr104327.c   -O3 -g  (test for excess errors)
FAIL: gcc.c-torture/compile/pr104327.c   -Os  (test for excess errors)
FAIL: gcc.c-torture/compile/pr58332.c   -O0  (test for excess errors)
FAIL: gcc.c-torture/compile/pr58332.c   -O1  (internal compiler error: 'global_options' are modified in local context)
FAIL: gcc.c-torture/compile/pr58332.c   -O1  (test for excess errors)
FAIL: gcc.c-torture/compile/pr58332.c   -O2  (internal compiler error: 'global_options' are modified in local context)
FAIL: gcc.c-torture/compile/pr58332.c   -O2  (test for excess errors)
FAIL: gcc.c-torture/compile/pr58332.c   -O3 -g  (internal compiler error: 'global_options' are modified in local context)
FAIL: gcc.c-torture/compile/pr58332.c   -O3 -g  (test for excess errors)
FAIL: gcc.c-torture/compile/pr58332.c   -Os  (internal compiler error: 'global_options' are modified in local context)
FAIL: gcc.c-torture/compile/pr58332.c   -Os  (test for excess errors)
FAIL: gcc.c-torture/compile/pr81360.c   -O0  (test for excess errors)
FAIL: gcc.c-torture/compile/pr81360.c   -O1  (internal compiler error: 'global_options' are modified in local context)
FAIL: gcc.c-torture/compile/pr81360.c   -O1  (test for excess errors)
FAIL: gcc.c-torture/compile/pr81360.c   -O2  (internal compiler error: 'global_options' are modified in local context)
FAIL: gcc.c-torture/compile/pr81360.c   -O2  (test for excess errors)
FAIL: gcc.c-torture/compile/pr81360.c   -O3 -g  (internal compiler error: 'global_options' are modified in local context)
FAIL: gcc.c-torture/compile/pr81360.c   -O3 -g  (test for excess errors)
FAIL: gcc.c-torture/compile/pr81360.c   -Os  (internal compiler error: 'global_options' are modified in local context)
FAIL: gcc.c-torture/compile/pr81360.c   -Os  (test for excess errors)
FAIL: gcc.c-torture/compile/pr84425.c   -O0  (test for excess errors)
FAIL: gcc.c-torture/compile/pr84425.c   -O1  (internal compiler error: 'global_options' are modified in local context)
FAIL: gcc.c-torture/compile/pr84425.c   -O1  (test for excess errors)
FAIL: gcc.c-torture/compile/pr84425.c   -O2  (internal compiler error: 'global_options' are modified in local context)
FAIL: gcc.c-torture/compile/pr84425.c   -O2  (test for excess errors)
FAIL: gcc.c-torture/compile/pr84425.c   -O3 -g  (internal compiler error: 'global_options' are modified in local context)
FAIL: gcc.c-torture/compile/pr84425.c   -O3 -g  (test for excess errors)
FAIL: gcc.c-torture/compile/pr84425.c   -Os  (internal compiler error: 'global_options' are modified in local context)
FAIL: gcc.c-torture/compile/pr84425.c   -Os  (test for excess errors)
With the following patch, none of those tests ICE anymore, though
pr104327.c still FAILs with:
Excess errors:
/usr/src/gcc/gcc/testsuite/gcc.c-torture/compile/pr104327.c:6:1: error: inlining failed in call to 'always_inline' 'bar': target specific option mismatch
I think that would be fixable by overriding TARGET_CAN_INLINE_P
hook and allowing at least for always_inline changes in sh_div_str.

2022-04-06  Jakub Jelinek  <jakub@redhat.com>

PR target/105069
* config/sh/sh.opt (mdiv=): Add Save.

--target-help: align with --help=target

PR driver/105096

gcc/ChangeLog:

* common.opt: Document properly based on what it does.
* gcc.cc (display_help): Unify with what we have in common.opt.
* opts.cc (common_handle_option): Do not print undocumented
options.

rs6000/testsuite: Skip pr105140.c

This test fails with error "AltiVec argument passed to unprototyped
function", but the code (in rs6000.c:invalid_arg_for_unprototyped_fn,
from 2005) actually tests for any vector type argument.  It also does
not fail on Darwin, not reflected here though.

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

gcc/testsuite/
PR target/105147
* gcc.dg/pr105140.c: Skip for powerpc*-*-*.

c++: -Wunused-value and array init [PR104702]

Here, because of problems with the new warning-control code and expressions
that change location, the suppress_warning on the INDIRECT_REF didn't work.
Those problems still need to be worked out, but it's simple to avoid needing
to use suppress_warning in the first place by using a reference instead.

PR c++/104702

gcc/cp/ChangeLog:

* init.cc (build_vec_init): Use a reference for the result.

gcc/testsuite/ChangeLog:

* g++.dg/warn/Wunused-19.C: New test.

mips: Fix C++14 vs. C++17 ABI incompatibility on mips64

This fixes tmpdir-g++.dg-struct-layout-1/{t032,t059} failure.  Clang++
also ignores C++17 empty bases in return values.

gcc/
* config/mips/mips.cc (mips_fpr_return_fields): Ignore
cxx17_empty_base_field_p fields and set an indicator.
(mips_return_in_msb): Adjust for mips_fpr_return_fields change.
(mips_function_value_1): Inform psABI change about C++17 empty
bases.

gcc/testsuite/
* g++.target/mips/cxx17_empty_base.C: New test.

gimple.cc: Follow-up to adjust gimple_call_builtin_p and gimple_call_combined_fn [PR105150]

On Wed, Apr 06, 2022 at 09:41:44AM +0100, Richard Sandiford wrote:
> But it seems like the magic incantation to detect “real” built-in
> function calls is getting longer and longer.  Can we not abstract this
> in a single place rather than have to repeat the same long sequence in
> multiple places?

I've already committed it, so it can be only dealt with an incremental
patch.
Here is a patch that adjusts instead gimple_builtin_call_types_compatible_p,
after the assert:
  if (DECL_BUILT_IN_CLASS (fndecl) == BUILT_IN_NORMAL)
    if (tree decl = builtin_decl_explicit (DECL_FUNCTION_CODE (fndecl)))
      fndecl = decl;
but we then lose the theoretical possibility of comparing against the
actual user declaration.  Though I guess in the
gimple-fold.cc
gimple-low.cc
gimple-match-head.cc
calls to that function we also want this rather than what they do currently.

2022-04-06  Jakub Jelinek  <jakub@redhat.com>

PR tree-optimization/105150
* gimple.cc (gimple_builtin_call_types_compatible_p): Use
builtin_decl_explicit here...
(gimple_call_builtin_p, gimple_call_combined_fn): ... rather than
here.

c++: -Wshadow=compatible-local type vs var [PR100608]

The patch for PR92024 changed -Wshadow=compatible-local to warn if either
new or old decl was a type, but the rationale only talked about the case
where both are types.  If only one is, they aren't compatible.

PR c++/100608

gcc/cp/ChangeLog:

* name-lookup.cc (check_local_shadow): Use -Wshadow=local
if exactly one of 'old' and 'decl' is a type.

gcc/testsuite/ChangeLog:

* g++.dg/warn/Wshadow-compatible-local-3.C: New test.

tree-optimization/105173 - fix insertion logic in reassoc

The find_insert_point logic around deciding whether to insert
before or after the found insertion point does not handle
the case of _12 = ..;, _12, 1.0 well.  The following puts the
logic into find_insert_point itself instead.

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

PR tree-optimization/105173
* tree-ssa-reassoc.cc (find_insert_point): Get extra
insert_before output argument and compute it.
(insert_stmt_before_use): Adjust.
(rewrite_expr_tree): Likewise.

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

ipa/105166 - avoid modref queries with mismatching types

We should avoid mismatched argument values (integers for pointers)
when doing modref queries.  This is the third place to guard.

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

PR ipa/105166
* ipa-modref-tree.cc (modref_access_node::get_ao_ref ): Bail
out for non-pointer arguments.

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

tree-optimization/105163 - abnormal SSA coalescing and reassoc

The negate propagation optimizations in reassoc did not look out for
abnormal SSA coalescing issues.  The following fixes that.

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

PR tree-optimization/105163
* tree-ssa-reassoc.cc (repropagate_negates): Avoid propagating
negated abnormals.

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

gimple.cc: Adjust gimple_call_builtin_p and gimple_call_combined_fn [PR105150]

On Tue, Apr 05, 2022 at 11:28:53AM +0200, Richard Biener wrote:
> > In GIMPLE, we call:
> >   && gimple_builtin_call_types_compatible_p (stmt, fndecl)
> > but that is insufficient, that verifies whether the arguments passed to
> > GIMPLE_CALL match the fndecl argument types.  But that fndecl may very well
> > be the user declaration, so doesn't have to match exactly the builtin
> > as predeclared by builtins.def etc. (though, there is the cotcha that say
> > for FILE * we just use void * etc.).  So e.g. in tree-ssa-strlen.cc
> > we use additional:
> >   tree callee = gimple_call_fndecl (stmt);
> >   tree decl = builtin_decl_explicit (DECL_FUNCTION_CODE (callee));
> >   if (decl
> >       && decl != callee
> >       && !gimple_builtin_call_types_compatible_p (stmt, decl))
> >     return false;
>
> Yeah, I think we should use that (and only that) function decl
> in get_call_combined_fn and gimple_call_combined_fn until the
> frontend stops slapping wrong BUILT_IN_* on random decls.

So, as a preparation step, this patch adjusts gimple_call_builtin_p
and gimple_call_combined_fn so that they check argument types against
the builtin_decl_explicit TYPE_ARG_TYPES rather than against the
actual used fndecl.

2022-04-06  Jakub Jelinek  <jakub@redhat.com>

PR tree-optimization/105150
* gimple.cc (gimple_call_builtin_p, gimple_call_combined_fn):
For BUILT_IN_NORMAL calls, call gimple_builtin_call_types_compatible_p
preferrably on builtin_decl_explicit decl rather than fndecl.
* tree-ssa-strlen.cc (valid_builtin_call): Don't call
gimple_builtin_call_types_compatible_p here.

vect: Fix mask handling for SLP gathers [PR103761]

check_load_store_for_partial_vectors predates the support for SLP
gathers and so had a hard-coded assumption that gathers/scatters
(and load/stores lanes) would be non-SLP operations.  This patch
passes down the slp_node so that the routine can work out how
many vectors are needed in both the SLP and non-SLP cases.

gcc/
PR tree-optimization/103761
* tree-vect-stmts.cc (check_load_store_for_partial_vectors): Replace
the ncopies parameter with an slp_node parameter.  Calculate the
number of vectors based on it and vectype.  Rename lambda to
group_memory_nvectors.
(vectorizable_store, vectorizable_load): Update calls accordingly.

gcc/testsuite/
PR tree-optimization/103761
* gcc.dg/vect/pr103761.c: New test.
* gcc.target/aarch64/sve/pr103761.c: Likewise.

docs: Document new param x86-stlf-window-ninsns.

gcc/ChangeLog:

* doc/invoke.texi: Document it.

tree-optimization/105148 - fix IVOPTs recording uses

The following fixes recording uses in ARRAY_REFs with non-constant
element size or low bound.

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

PR tree-optimization/105148
* tree-ssa-loop-ivopts.cc (idx_record_use): Walk raw operands
2 and 3 of ARRAY_REFs.

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

Support pandn for V1TI mode (i.e. *andnotv1ti3).

This simple patch allows the i386 backend to generate pandn instructions
for V1TI mode.  Currently, the testcase:

typedef unsigned __int128 v1ti __attribute__ ((__vector_size__ (16)));
v1ti andnot1(v1ti x, v1ti y) { return ~x & y; }

generates with -O2

        pcmpeqd %xmm2, %xmm2
        pxor    %xmm2, %xmm0
        pand    %xmm1, %xmm0
        ret

with this patch, we now generate:

        pandn   %xmm1, %xmm0
        ret

It turns out that there are currently three (near) duplicates of the
logic for andn/pandn/vandn/vpandn in i386/sse.md: one for floating point
vectors (MODEF), one for integer vectors (VI) and a third for TFmode.
Rather than introduce a fourth copy, this patch introduces a new mode
iterator to share/reuse the TFmode define_insn to also handle V1TI.

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

gcc/ChangeLog
* config/i386/sse.md (ANDNOT_MODE): New mode iterator for TF and V1TI.
(*andnottf3): Replace with...
(*andnot<mode>3): New define_insn using ANDNOT_MODE.

gcc/testsuite/ChangeLog
* gcc.target/i386/sse2-v1ti-andnot.c: New test case.

tree-optimization/105142 - wrong code with maybe_fold_{and,or}_comparisons

The following avoids expanding definitions in regions conditionally
executed under the condition A when simplifying A && B or A || B.
This is done by passing down the basic-block of the outer condition
to maybe_fold_{and,or}_comparisons, through the various helpers
in gimple-fold.cc that might call back to maybe_fold_{and,or}_comparisons
and ultimatively to maybe_fold_comparisons_from_match_pd where the
fix is to provide a custom valueization hook to
gimple_match_op::resimplify that avoids looking at definitions
that do not dominate the outer block.

For the testcase this avoids combining a stmt that invokes undefined
integer overflow when the outer condition is false but it also
aovids combining stmts with range information that is derived from
the outer condition.

The new parameter to maybe_fold_{and,or}_comparisons is defaulted
to nullptr and I only adjusted the if-combine to pass down the
outer block.  I think other callers like tree-if-conv have the
same issue but it's not straight-forward as to what to do there.

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

PR tree-optimization/105142
* gimple-fold.h (maybe_fold_and_comparisons): Add defaulted
basic-block parameter.
(maybe_fold_or_comparisons): Likewise.
* gimple-fold.cc (follow_outer_ssa_edges): New.
(maybe_fold_comparisons_from_match_pd): Use follow_outer_ssa_edges
when an outer condition basic-block is specified.
(and_comparisons_1, and_var_with_comparison,
and_var_with_comparison_1, or_comparisons_1,
or_var_with_comparison, or_var_with_comparison_1): Receive and pass
down the outer condition basic-block.
* tree-ssa-ifcombine.cc (ifcombine_ifandif): Pass down the
basic-block of the outer condition.

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

testsuite/105122 - adjust testcases after memcpy folding changes

After r12-7931 we again honor MOVE_MAX when folding memcpy to
a load/store pair.  On i?86-*-* without SSE this now exposes the
change done in r12-2666-g29f0e955c97da0 which adjusts MOVE_MAX
from 16 to 4 on those targets.  This makes adjusting testcases
necessary that assume that we transform memcpy to load/store pairs
on GIMPLE for sizes larger or equal to 8.

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

PR testsuite/105122
* gcc.dg/memcpy-6.c: Adjust.
* gcc.dg/strlenopt-73.c: Likewise.
* gcc.dg/strlenopt-80.c: Likewise.

rs6000: Support UN[GL][ET] in rs6000_maybe_emit_maxc_minc [PR105002]

Commit r12-7687 exposed one miss optimization chance in function
rs6000_maybe_emit_maxc_minc, for now it only considers comparison
codes GE/GT/LE/LT, but it can support more variants with codes
UNLT/UNLE/UNGT/UNGE by reversing them into the equivalent ones
with GE/GT/LE/LT.

gcc/ChangeLog:

PR target/105002
* config/rs6000/rs6000.cc (rs6000_maybe_emit_maxc_minc): Support more
comparison codes UNLT/UNLE/UNGT/UNGE.

Daily bump.

libbacktrace: don't skip initial aligned byte in uncompressed block

Patch from Rui Ueyama, who says:

libbacktrace occasionally fails to decompress compressed debug info
even though the sections contain valid zlib streams. The cause of the
issue is an off-by-one error.

If a zlib data block is a plain data (uncompressed data), the next two
bytes contain the size of the block. These two bytes value is byte-
aligned, so if we read-ahead more than 8 bits, we need to unread it.

So, the correct condition to determine whether or not we need to
unread a byte is bits >= 8 and not bits > 8. Due to this error,
if the last read bits happened to end at a byte boundary, the next
byte would be skipped. That caused the decompression failure.

This bug was originally reported against the mold linker.
rui314/mold#402

* elf.c (elf_zlib_inflate): Don't skip initial aligned byte in
uncompressed block.

Document that the 'access' and 'nonnull' attributes are independent

gcc/ChangeLog:
* doc/extend.texi (Common Function Attributes): Document that
'access' does not imply 'nonnull'.

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

Update gcc .po files

* be.po, da.po, de.po, el.po, es.po, fi.po, fr.po, hr.po, id.po,
ja.po, nl.po, ru.po, sr.po, sv.po, tr.po, uk.po, vi.po, zh_CN.po,
zh_TW.po: Update.

Fortran: Fix clause splitting for OMP masked taskloop directive

This patch fixes an obvious coding goof that caused all clauses for
the combined OMP masked taskloop directive to be discarded.

gcc/fortran/
* trans-openmp.cc (gfc_split_omp_clauses): Fix mask for
EXEC_OMP_MASKED_TASKLOOP.

gcc/testsuite/
* gfortran.dg/gomp/masked-taskloop.f90: New.

i386: Fix movv2qi_internal xmm reg to xmm reg move for AVX512FP16 [PR105139]

2022-04-05  Uroš Bizjak  <ubizjak@gmail.com>

gcc/ChangeLog:

PR target/105139
* config/i386/mmx.md (*movv2qi_internal):
Change insn mode of alternative 5 to HF for TARGET_AVX512FP16.

gcc/testsuite/ChangeLog:

PR target/105139
* gcc.target/i386/pr105139.c: New test.

Fortran: improve error recovery for invalid coarray function declarations

gcc/fortran/ChangeLog:

PR fortran/104210
* arith.cc (eval_intrinsic): Avoid NULL pointer dereference.
(gfc_zero_size_array): Likewise.

gcc/testsuite/ChangeLog:

PR fortran/104210
* gfortran.dg/pr104210.f90: New test.

Fortran: a RECURSIVE procedure cannot be an INTRINSIC

gcc/fortran/ChangeLog:

PR fortran/105138
* intrinsic.cc (gfc_is_intrinsic): When a symbol refers to a
RECURSIVE procedure, it cannot be an INTRINSIC.

gcc/testsuite/ChangeLog:

PR fortran/105138
* gfortran.dg/recursive_reference_3.f90: New test.

Co-authored-by: Steven G. Kargl <kargl@gcc.gnu.org>

aarch64: Stop +mops clobbering variable values

The mops cpy* patterns take three registers: a destination address,
a source address, and a size.  The patterns clobber all three registers
as part of the operation.  The set* patterns take a destination address,
a size, and a store value, and they clobber the first two registers as
part of the operation.

However, the associated expanders would try to use existing source,
destination and size registers where possible.  Any variables in
those registers could therefore change unexpectedly.

For example:

    void
    copy1 (int *x, int *y, long z, int **res)
    {
      __builtin_memcpy (x, y, z);
      *res = x;
    }

generated:

        cpyfp   [x0]!, [x1]!, x2!
        cpyfm   [x0]!, [x1]!, x2!
        cpyfe   [x0]!, [x1]!, x2!
        str     x0, [x3]
        ret

which stores the incremented x at *res.

gcc/
* config/aarch64/aarch64.md (aarch64_cpymemdi): Turn into a
define_expand and turn operands 0 and 1 from REGs to MEMs.
(*aarch64_cpymemdi): New pattern.
(aarch64_setmemdi): Turn into a define_expand and turn operand 0
from a REG to a MEM.
(*aarch64_setmemdi): New pattern.
* config/aarch64/aarch64.cc (aarch64_expand_cpymem_mops): Use
copy_to_mode_reg on all three registers.  Replace the original
MEM addresses rather than creating wild reads and writes.
(aarch64_expand_setmem_mops): Likewise for the size and for the
destination memory and address.

gcc/testsuite/
* gcc.target/aarch64/mops_4.c: New test.

aarch64: Fix -fpack-struct + <arm_neon.h> [PR103147]

This PR is about -fpack-struct causing a crash when <arm_neon.h>
is included.  The new register_tuple_type code was expecting a
normal unpacked structure layout instead of a packed one.

For SVE we got around this by temporarily suppressing -fpack-struct,
so that the tuple types always have their normal ABI.  However:

(a) The SVE ACLE tuple types are defined to be abstract.  The fact
    that GCC uses structures is an internal implementation detail.

(b) In contrast, the ACLE explicitly defines the Advanced SIMD
    tuple types to be particular structures.

(c) Clang and previous versions of GCC are consistent in applying
    -fpack-struct to these tuple structures.

This patch therefore honours -fpack-struct and -fpack-struct=.  It also
adds tests for some other combinations, such as -mgeneral-regs-only and
-fpack-struct -mstrict-align.

gcc/
PR target/103147
* config/aarch64/aarch64-protos.h (aarch64_simd_switcher): New class.
* config/aarch64/aarch64-sve-builtins.h (sve_switcher): Inherit
from aarch64_simd_switcher.
* config/aarch64/aarch64-builtins.cc (aarch64_simd_tuple_modes):
New variable.
(aarch64_lookup_simd_builtin_type): Use it instead of TYPE_MODE.
(register_tuple_type): Add more asserts.  Expect the alignment
of the structure to be subject to flag_pack_struct and
maximum_field_alignment.  Set aarch64_simd_tuple_modes.
(aarch64_simd_switcher::aarch64_simd_switcher): New function.
(aarch64_simd_switcher::~aarch64_simd_switcher): Likewise.
(handle_arm_neon_h): Hold an aarch64_simd_switcher throughout.
(aarch64_general_init_builtins): Hold an aarch64_simd_switcher
while calling aarch64_init_simd_builtins.
* config/aarch64/aarch64-sve-builtins.cc (sve_switcher::sve_switcher)
(sve_switcher::~sve_switcher): Remove code now performed by
aarch64_simd_switcher.

gcc/testsuite/
PR target/103147
* gcc.target/aarch64/pr103147-1.c: New test.
* gcc.target/aarch64/pr103147-2.c: Likewise.
* gcc.target/aarch64/pr103147-3.c: Likewise.
* gcc.target/aarch64/pr103147-4.c: Likewise.
* gcc.target/aarch64/pr103147-5.c: Likewise.
* gcc.target/aarch64/pr103147-6.c: Likewise.
* gcc.target/aarch64/pr103147-7.c: Likewise.
* gcc.target/aarch64/pr103147-8.c: Likewise.
* gcc.target/aarch64/pr103147-9.c: Likewise.
* gcc.target/aarch64/pr103147-10.c: Likewise.
* g++.target/aarch64/pr103147-1.C: Likewise.
* g++.target/aarch64/pr103147-2.C: Likewise.
* g++.target/aarch64/pr103147-3.C: Likewise.
* g++.target/aarch64/pr103147-4.C: Likewise.
* g++.target/aarch64/pr103147-5.C: Likewise.
* g++.target/aarch64/pr103147-6.C: Likewise.
* g++.target/aarch64/pr103147-7.C: Likewise.
* g++.target/aarch64/pr103147-8.C: Likewise.
* g++.target/aarch64/pr103147-9.C: Likewise.
* g++.target/aarch64/pr103147-10.C: Likewise.

aarch64: Use error_n for plural text [PR104897]

Use error_n rather than error_at for “%d vectors”, so that
translators can pick different translations based on the
number (2 vs more than 2, etc.)

gcc/
PR target/104897
* config/aarch64/aarch64-sve-builtins.cc
(function_resolver::infer_vector_or_tuple_type): Use error_n
for "%d vectors" messages.