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.

c++: alias template equivalence and CTAD [PR103852]

I had been thinking about DR1286 "equivalence" as meaning generally
interchangeable, but looking back at the proposed resolution in the context
of this PR, I see that it's just about use as a template argument.  So let's
give a pedwarn if we look through a renaming alias.

PR c++/103852
DR 1286

gcc/cp/ChangeLog:

* pt.cc (do_class_deduction): Pedwarn for renaming alias in C++17.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1z/class-deduction-alias1.C: Expect warning.

c++: elaborated-type-spec in requires-expr [PR101677]

We were failing to declare class S in the global namespace because we were
treating the requires-expression parameter scope as a normal block scope, so
the implicit declaration went there.

It seems to me that the requires parameter scope is more like a function
parameter scope (not least in the use of the word "parameter"), so let's
change the scope kind.  But then we need to adjust the prohibition on
placeholders declaring implicit template parameters.

PR c++/101677

gcc/cp/ChangeLog:

* name-lookup.h (struct cp_binding_level): Add requires_expression
bit-field.
* parser.cc (cp_parser_requires_expression): Set it.
(synthesize_implicit_template_parm): Check it.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts-pr67178.C: Adjust error.
* g++.dg/cpp2a/concepts-requires28.C: New test.

c++: adjust testcase

This test was failing with -std=c++23 -fimplicit-constexpr (not tested by
default) due to different wording in the error message.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/noexcept34.C: Allow more wording variation.

OpenMP: Fix nested use_device_ptr

This patch fixes a bug in lower_omp_target, where for Fortran arrays,
the expanded sender assignment is wrongly using the variable in the
current ctx, instead of the one looked-up outside, which is causing
use_device_ptr/addr to fail to work when used inside an omp-parallel
(where the omp child_fn is split away from the original).

The fix is inside omp-low.cc, though because the omp_array_data langhook
is used only by Fortran, this is essentially Fortran-specific.

2022-04-05  Chung-Lin Tang  <cltang@codesourcery.com>

gcc/ChangeLog:

* omp-low.cc (lower_omp_target): Use outer context looked-up 'var' as
argument to lang_hooks.decls.omp_array_data, instead of 'ovar' from
current clause.

libgomp/ChangeLog:

* testsuite/libgomp.fortran/use_device_ptr-4.f90: New testcase.

c/105151 - move early walloca pass

When the walloca pass gained support for ranger the early pass
was not moved to a place where SSA form is available but remained
in the lowering pipeline.  For the testcase in this bug this is
a problem because for errorneous input we still run the lowering
pipeline but here have broken SSA form which ranger does not like.
The solution is to rectify the mistake with using ranger without
SSA form and move the pass which solves both issues.

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

PR c/105151
* passes.def (pass_walloca): Move early instance into
pass_build_ssa_passes to make SSA form available.

* gcc.dg/gimplefe-error-14.c: New testcase.

testsuite/s390: Adapt test expections.

Some tests expect a convert instruction but nowadays
(r12-4475-g247c407c83f001) the conversion is already done at compile
time.  This results in a literal-pool load.  Change the tests accordingly.

gcc/testsuite/ChangeLog:

* gcc.target/s390/zvector/vec-double-compile.c: Expect vl
  instead of vc*.
* gcc.target/s390/zvector/vec-float-compile.c: Dito.
* gcc.target/s390/zvector/vec-signed-compile.c: Dito.
* gcc.target/s390/zvector/vec-unsigned-compile.c: Dito.

testsuite/s390: Change nle -> h in ifcvt tests.

We have been emitting the "higher" variantes instead of the "not less or equal"
ones for a while.  Change the test expectations accordingly.

gcc/testsuite/ChangeLog:

* gcc.target/s390/ifcvt-two-insns-bool.c: Change nle to h.
* gcc.target/s390/ifcvt-two-insns-int.c: Dito.
* gcc.target/s390/ifcvt-two-insns-long.c: Dito.

testsuite: Add -fno-tree-loop-distribute-patterns.

In gcc.dg/Wuse-after-free-2.c we try to detect a use-after-free.  The
test's while loop is converted into a rawmemchr builtin making
it impossible to determine that the pointers *p and *q are related.

Therefore, disable the tree loop distribute patterns pass for this test.

gcc/testsuite/ChangeLog:

* gcc.dg/Wuse-after-free-2.c:
Add -fno-tree-loop-distribute-patterns in order to avoid
rawmemchr.

Split vector load from parm_del to elemental loads to avoid STLF stalls.

Since cfg is freed before machine_reorg, just do a rough calculation
of the window according to the layout.
Also according to an experiment on CLX, set window size to 64.

Currently only handle V2DFmode load since it doesn't need any scratch
registers, and it's sufficient to recover cray performance for -O2
compared to GCC11.

gcc/ChangeLog:

PR target/101908
* config/i386/i386.cc (ix86_split_stlf_stall_load): New
function
(ix86_reorg): Call ix86_split_stlf_stall_load.
* config/i386/i386.opt (-param=x86-stlf-window-ninsns=): New
param.

gcc/testsuite/ChangeLog:

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

try multi-reg dest in default_zero_call_used_regs

When the mode of regno_reg_rtx is not hard_regno_mode_ok for the
target, try grouping the register with subsequent ones.  This enables
s16 to s31 and their hidden pairs to be zeroed with the default logic
on some arm variants.

for  gcc/ChangeLog

* targhooks.cc (default_zero_call_used_regs): Attempt to group
regs that the target refuses to use in their natural modes.
(zcur_select_mode_rtx): New.
* regs.h (struct target_regs): Add x_hard_regno_max_nregs.
(hard_regno_max_nregs): Define.
* reginfo.cc (init_reg_modes_target): Set hard_regno_max_nregs.

Daily bump.

Update gcc sv.po

* sv.po: Update.

doc: Fix typos in match.pd documentation

This patch fixes some spelling and grammar issues in the match.pd
documentation.

gcc/ChangeLog:

* doc/match-and-simplify.texi: Fix typos.

c++: repeated friend template [PR101894]

Since olddecl isn't a definition, it doesn't get DECL_FRIEND_CONTEXT, so we
need to copy it from newdecl when we merge the declarations.

PR c++/101894

gcc/cp/ChangeLog:

* decl.cc (duplicate_decls): Copy DECL_FRIEND_CONTEXT.

gcc/testsuite/ChangeLog:

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

c++: alias-tmpl equivalence and default targs [PR103852]

The suggested resolution for CWG1286, which we implemented, ignores default
template arguments, but this PR is an example of why that doesn't make
sense: the templates aren't functionally equivalent.

PR c++/103852
DR 1286

gcc/cp/ChangeLog:

* pt.cc (get_underlying_template): Compare default template args.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/alias-decl-dr1286a.C: Default args now matter.
* g++.dg/cpp1z/class-deduction-alias1.C: New test.

aarch64: Restrict aarch64-tune.md regeneration to --enable-maintainer-mode [PR105144]

Normally updates to the source directory files are guarded with
--enable-maintainer-mode, e.g. we don't regenerate configure, config.h,
Makefile.in in directories that use automake etc. unless gcc is configured
that way.  Otherwise the source tree can't be e.g. stored on a read-only
filesystem etc.
In gcc/Makefile.in we use @MAINT@ for that but that works because
gcc/Makefile is generated by configure.  In config/*/t-* files we need to
check $(ENABLE_MAINTAINER_RULES):
 # The following provides the variable ENABLE_MAINTAINER_RULES that can
 # be used in language Make-lang.in makefile fragments to enable
 # maintainer rules.  So, ENABLE_MAINTAINER_RULES is 'true' in
 # maintainer mode, and '' otherwise.
 @MAINT@ ENABLE_MAINTAINER_RULES = true

On Mon, Apr 04, 2022 at 11:10:14AM +0100, Richard Sandiford wrote:
> I guess the risk is that it will become even easier to forget
> to commit an updated aarch64-tune.md.  Perhaps we should have a
> non-maintainer rule to build aarch64-tune.md locally and check it
> against the source-directory version, and fail the build if there's
> a mismatch.  Or maybe we should just generate aarch64-tune.md in the
> build directory and remove the source directory version.

I've tried if aarch64-tune.md will be read from the build dir, but it is
not.  The gen* files can use -I options to add additional directories, but
they don't use them.

Here is a variant patch which will complain and fail if there is a change
and --enable-maintainer-mode is not enabled.

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

PR target/105144
* config/aarch64/t-aarch64 (s-aarch64-tune-md): Do move-if-change
only if configured with --enable-maintainer-mode, otherwise compare
tmp-aarch64-tune.md with $(srcdir)/config/aarch64/aarch64-tune.md and
if they differ, emit a message and fail.

[libgomp/testsuite] Fix libgomp.fortran/examples-4/declare_target-{1,2}.f90

The test-cases libgomp.fortran/examples-4/declare_target-{1,2}.f90 mean to
set an nvptx-specific limit using offload_target_nvptx, but also change
behaviour for amd.

That is, there is now a difference in behaviour between:
- a compiler configured for GCN offloading, and
- a compiler configured for both GCN and nvptx offloading.

Fix this by using instead on_device_arch_nvptx.

Tested on x86_64 with nvptx accelerator.

libgomp/ChangeLog:

2022-04-04  Tom de Vries  <tdevries@suse.de>

* testsuite/libgomp.fortran/examples-4/declare_target-1.f90: Use
on_device_arch_nvptx instead of offload_target_nvptx.
* testsuite/libgomp.fortran/examples-4/declare_target-2.f90: Same.

aarch64: Fix aarch64-tune.md (re)generation [PR105144]

As I wrote in the PR, our Fedora trunk gcc builds likely after r12-7842
change are now failing (lto1 crashes).
What happens is that when one bootstraps into an empty build directory
(or set of them), mddeps.mk doesn't exist yet and so Makefile doesn't
include it.  When building from an empty dir, that is usually not a big
issue, it is enough when various build directory files depend on just
$(srcdir)/config/aarch64/aarch64.md, those files don't exist and
aarch64.md does, so they are built, so is mddeps.mk.
But because the other dependencies aren't there (in particular
$(srcdir)/config/aarch64/aarch64-tune.md ), the
s-aarch64-tune-md rule isn't invoked to regenerate that file and the
r12-7842 commit reordered aarch64-cores.def entries but didn't commit
regenerated aarch64-tune.md.  Because it is just reordering in
aarch64-tune.md, it actually doesn't matter and bootstraps succeeds.
But then during make install, mddeps.mk exists already in gcc/ directory,
it sees that aarch64-cores.def is newer than aarch64-tune.md (unless
gen_update is used, that just touches aarch64-tune.md to make sure it
is newer) and regenerates it and as it is different, make install rebuilds
a large subset of the *.o files, but this time with the system g++
rather than previous stage one.  And during lto linking of it there
are differences in LTO bytecode between the compilers and we crash.

The following patch fixes that by regenerating aarch64-tune.md
(what was forgotten in r12-7842) and by adding a dependency from
s-mddeps to s-aarch64-tune-md, which makes sure that even when mddeps.mk
doesn't exist yet make sees the dependency and regenerates aarch64-tune.md
if needed.

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

PR target/105144
* config/aarch64/t-aarch64 (s-mddeps): Depend on s-aarch64-tune-md.
* config/aarch64/aarch64-tune.md: Regenerated.

tree-optimization/105132 - add missing checking in vectorizable_operation

The following adds missing verification that the input vectors
have the same number of elements for vectorizable_operation.

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

PR tree-optimization/105132
* tree-vect-stmts.cc (vectorizable_operation): Check that
the input vectors have the same number of elements.

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

middle-end/105140 - fix bogus recursion in fold_convertible_p

fold_convertible_p expects an operand and a type to convert to
but recurses with two vector component types.  Fixed by allowing
types instead of an operand as well.

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

PR middle-end/105140
* fold-const.cc (fold_convertible_p): Allow a TYPE_P arg.

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

d: Compile simd_ctfe.d only on avx_runtime or vect_sizes_16B_8B targets

PR d/104740

gcc/testsuite/ChangeLog:

* gdc.dg/simd_ctfe.d: Compile with target avx_runtime or
vect_sizes_16B_8B.

Add ChangeLog entries for 86d8e0c0652ef5236a460b75c25e4f7093cc0651.

gcc/cp/ChangeLog:

* ChangeLog: Add entry for
86d8e0c0652ef5236a460b75c25e4f7093cc0651.

gcc/testsuite/ChangeLog:

* ChangeLog: Add entry for
86d8e0c0652ef5236a460b75c25e4f7093cc0651.

Daily bump.

gcc-changelog: ignore one more revision

Ignore:

Checking 86d8e0c0652ef5236a460b75c25e4f7093cc0651: FAILED
ERR: line should start with a tab: "This reverts commits r12-7804 and r12-7929."
ERR: could not deduce ChangeLog file

contrib/ChangeLog:

* gcc-changelog/git_update_version.py: Ignore the revision.

[committed][PR target/104987] Avoid "likely" forms of bbi[n] on iq2000.

The iq2000 port is mis-compiling its mulsi3 libgcc2 function.

AFAICT, the iq2000 has delay slots and can use "branch-likely" forms of conditional branches to annul-false the slot.   There's a support routine that handles creation of the  likely form.  However, that routine is not used by the bbi[n] instructions.

If I manually add the likely extension to the bbi[b] instructions, the assembler complains  After a fair amount of digging it appears that the likely forms of bbi[n] are only supported on the IQ10 variant.

Given this is a dead processor and has been so for a while it seems reasonable to just disallow annul-false slots for the bbi[n] instructions rather than try to handle them just for the IQ10 (which we don't have real support for anyway).

This (of course) fixes the vrp13 regression.  But it also fixes nearly a thousand execution test failures in the testsuite (Yow!).

gcc/
PR target/104987
* config/iq2000/iq2000.md (bbi): New attribute,  default to no.
(delay slot descripts): Use different delay slot description when
the insn as the "bbi" attribute.
(bbi, bbin patterns): Set the bbi attribute to yes.

i386: Fix up ix86_expand_vector_init_general [PR105123]

The following testcase is miscompiled on ia32.
The problem is that at -O0 we end up with:
  vector(4) short unsigned int _1;
  short unsigned int u.0_3;
...
  _1 = {u.0_3, u.0_3, u.0_3, u.0_3};
statement (dead) which is wrongly expanded.
elt is (subreg:HI (reg:SI 83 [ u.0_3 ]) 0), tmp_mode SImode,
so after convert_mode we start with word (reg:SI 83 [ u.0_3 ]).
The intent is to manually broadcast that value to 2 SImode parts,
but because we pass word as target to expand_simple_binop, it will
overwrite (reg:SI 83 [ u.0_3 ]) and we end up with 0:
   10: {r83:SI=r83:SI<<0x10;clobber flags:CC;}
   11: {r83:SI=r83:SI|r83:SI;clobber flags:CC;}
   12: {r83:SI=r83:SI<<0x10;clobber flags:CC;}
   13: {r83:SI=r83:SI|r83:SI;clobber flags:CC;}
   14: clobber r110:V4HI
   15: r110:V4HI#0=r83:SI
   16: r110:V4HI#4=r83:SI
as the two ors do nothing and two shifts each by 16 left shift it all
away.
The following patch fixes that by using NULL_RTX target, so we expand it as
   10: {r110:SI=r83:SI<<0x10;clobber flags:CC;}
   11: {r111:SI=r110:SI|r83:SI;clobber flags:CC;}
   12: {r112:SI=r83:SI<<0x10;clobber flags:CC;}
   13: {r113:SI=r112:SI|r83:SI;clobber flags:CC;}
   14: clobber r114:V4HI
   15: r114:V4HI#0=r111:SI
   16: r114:V4HI#4=r113:SI
instead.

Another possibility would be to pass NULL_RTX only when word == elt
and word otherwise, where word would necessarily be a pseudo from the first
shift after passing NULL_RTX there once or pass NULL_RTX for the shift and
word for ior.

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

PR target/105123
* config/i386/i386-expand.cc (ix86_expand_vector_init_general): Avoid
using word as target for expand_simple_binop when doing ASHIFT and
IOR.

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

d: Remove Wtemplates warnings from the code generation pass

These have been superceded by the front-end's own internal tracking of
instantiations, exposed by `-ftransition=templates'.

gcc/d/ChangeLog:

* d-lang.cc: Include dmd/template.h.
(d_parse_file): Call printTemplateStats when vtemplates is set.
* decl.cc (start_function): Remove OPT_Wtemplates warning.
* lang.opt (Wtemplates): Remove.

c++: Fix ICE due to shared BLOCK node in coroutine generation [PR103328]

When finishing a function that is a coroutine, the function is
transformed into a "ramp" function, and the original user-provided
function body gets moved into a newly created "actor" function.

In this case `current_function_decl` points to the ramp function,
but `current_binding_level->blocks` would still point to the
scope block of the user-provided function body in the actor function,
so when the ramp function was finished during `poplevel()` in decl.cc,
we could end up with that block being reused as the `DECL_INITIAL()` of
the ramp function:

   subblocks = functionbody >= 0 ? current_binding_level->blocks : 0;
   // [...]
   DECL_INITIAL (current_function_decl) = block ? block : subblocks;

This block would then be independently modified by subsequent passes
touching either the ramp or the actor function, potentially causing
an ICE depending on the order and function of these passes.

gcc/cp/ChangeLog:

PR c++/103328
* coroutines.cc (morph_fn_to_coro): Reset
current_binding_level->blocks.

gcc/testsuite/ChangeLog:

PR c++/103328
* g++.dg/coroutines/pr103328.C: New test.

Co-Authored-By: Iain Sandoe <iain@sandoe.co.uk>

d: Merge upstream dmd 47871363d, druntime, c52e28b7, phobos 99e9c1b77.

D front-end changes:

    - Import dmd v2.099.1-beta.1.
    - The address of NRVO variables is now stored in scoped closures
      when they have nested references.
    - Using `__traits(parameters)' in foreach loops now always returns
      the parameters to the function the foreach appears within.
      Previously, when used inside a `foreach' using an overloaded
      `opApply', the trait would yield the parameters to the delegate.
    - The deprecation period of unannotated `asm' blocks has been ended.
    - The `inout' attribute no longer implies the `return' attribute.
    - Added new `D_PreConditions', `D_PostConditions', and
      `D_Invariants' version identifiers.

D runtime changes:

    - Import druntime v2.099.1-beta.1.

Phobos changes:

    - Import phobos v2.099.1-beta.1.
    - `Nullable' in `std.typecons' can now act as a range.
    - std.experimental.logger default level changed to `info' instead of
      `warning'.

gcc/d/ChangeLog:

* dmd/MERGE: Merge upstream dmd 47871363d.
* d-builtins.cc (d_init_versions): Add predefined version identifiers
D_PreConditions, D_PostConditions, and D_Invariants.
* d-codegen.cc (d_build_call): Update for new front-end interface.
(build_frame_type): Generate reference field for NRVO variables with
nested references.
(build_closure): Generate assignment of return address to closure.
* d-tree.h (DECL_INSTANTIATED): Use DECL_LANG_FLAG_2.
(bind_expr): Remove.
* decl.cc (DeclVisitor::visit (FuncDeclaration *)): Update for new
front-end interface.
(get_symbol_decl): Likewise.
(get_decl_tree): Check DECL_LANG_FRAME_FIELD before DECL_LANG_NRVO.
Dereference the field when both are set.
* expr.cc (ExprVisitor::visit (DeleteExp *)): Update for new front-end
interface.
* modules.cc (get_internal_fn): Likewise.
* toir.cc (IRVisitor::visit (ReturnStatement *)): Likewise.

libphobos/ChangeLog:

* libdruntime/MERGE: Merge upstream druntime c52e28b7.
* libdruntime/Makefile.am (DRUNTIME_DSOURCES_OPENBSD): Add
core/sys/openbsd/pwd.d.
* libdruntime/Makefile.in: Regenerate.
* src/MERGE: Merge upstream phobos 99e9c1b77.
* testsuite/libphobos.exceptions/message_with_null.d: New test.

gcc/testsuite/ChangeLog:

* gdc.dg/nrvo1.d: New test.

mips: Fix an ICE caused by r12-7962

DECL_SIZE(x) is NULL if x is a flexible array member, but I forgot to
check it in r12-7962.  Then if we increase the size of a struct with
flexible array member (by using aligned attribute), the code will
dereference NULL trying to use the "size" of the flexible array member.

gcc/

* config/mips/mips.cc (mips_function_arg): Check if DECL_SIZE is
NULL before dereferencing it.

gcc/testsuite/

* gcc.target/mips/pr102024-4.c: New test.

libstdc++: Tweak source_location for clang trunk [PR105128]

Apparently clang trunk implemented __builtin_source_location(), but the
using __builtin_ret_type = decltype(__builtin_source_location());
which has been added for it isn't enough, they also need the
std::source_location::__impl class to be defined (but incomplete seems
to be good enough) before the builtin is used.

The following has been tested on godbolt with clang trunk (old version
fails with
error: 'std::source_location::__impl' was not found; it must be defined before '__builtin_source_location' is called
and some follow-up errors), getting back to just void * instead of
__builtin_ret_type and commenting out using doesn't work either and
just struct __impl; before using __builtin_ret_type doesn't work too.

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

PR libstdc++/105128
* include/std/source_location (std::source_location::__impl): Move
definition before using __builtin_ret_type.

fixed-point/composite-type: add -Wno-array-parameter

On machines that support fixed-point and the test runs, it's failing
because of warnings issued by -Warray-parameter=[12], enabled by
-Wall.

The warnings state "mismatch in bound 1 of argument 1 declared as...",
referring to the redeclaration of f2_##NAME.  The purpose of the
redeclaration is not clear to me.

It doesn't look like the test intends to catch mismatches between
parameter's array lengths, despite the explicit array bound and the
incompatible calls, so I'm adding -Wno-array-parameter to avoid this
distraction and enable the test to pass.

for gcc/testsuite/ChangeLog

* gcc.dg/fixed-point/composite-type.c: Add -Wno-array-parameter.

c++: deducing from class type of NTTP [PR105110]

Here when attempting to deduce T in the NTTP type A<T> from the argument
type 'const A<int>', we give up due to the const:

  types ‘A<T>’ and ‘const A<int>’ have incompatible cv-qualifiers

But since the type of an NTTP cannot be cv-qualified, it seems natural
to ignore cv-qualifiers on the argument type before attempting to unify
the two types.

PR c++/105110

gcc/cp/ChangeLog:

* pt.cc (unify) <case TEMPLATE_PARM_INDEX>: Drop cv-quals from
the argument type of an NTTP before deducing from it.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/nontype-class52.C: New test.

Regenerate gcc.pot

* gcc.pot: Regenerate.

Update gcc hr.po

* hr.po: Update.

Add an assertion: the zeroed_hardregs set is a subset of all call used regs.

We should make sure that the hard register set that is actually cleared by
the target hook zero_call_used_regs should be a subset of all call used
registers.

At the same time, update documentation for the target hook
TARGET_ZERO_CALL_USED_REGS.

This new assertion identified a bug in the i386 implemenation, which
incorrectly set the zeroed_hardregs for stack registers. Fixed this bug
in i386 implementation.

gcc/ChangeLog:

2022-04-01  Qing Zhao  <qing.zhao@oracle.com>

* config/i386/i386.cc (zero_all_st_registers): Return the value of
num_of_st.
(ix86_zero_call_used_regs): Update zeroed_hardregs set according to
the return value of zero_all_st_registers.
* doc/tm.texi: Update the documentation of TARGET_ZERO_CALL_USED_REGS.
* function.cc (gen_call_used_regs_seq): Add an assertion.
* target.def: Update the documentation of TARGET_ZERO_CALL_USED_REGS.

mips: Ignore zero width fields in arguments and issue -Wpsabi warning about C zero-width field ABI changes [PR102024]

gcc/
PR target/102024
* config/mips/mips.cc (mips_function_arg): Ignore zero-width
fields, and inform if it causes a psABI change.

gcc/testsuite/
PR target/102024
* gcc.target/mips/pr102024-1.c: New test.
* gcc.target/mips/pr102024-2.c: New test.
* gcc.target/mips/pr102024-3.c: New test.

mips: Emit psabi diagnostic for return values affected by C++ zero-width bit-field ABI change [PR 102024]

gcc/
PR target/102024
* config/mips/mips.cc (mips_fpr_return_fields): Detect C++
zero-width bit-fields and set up an indicator.
(mips_return_in_msb): Adapt for mips_fpr_return_fields change.
(mips_function_value_1): Diagnose when the presense of a C++
zero-width bit-field changes function returning in GCC 12.

gcc/testsuite/
PR target/102024
* g++.target/mips/mips.exp: New test supporting file.
* g++.target/mips/pr102024.C: New test.

Revert "c++: delayed parse DMI [PR96645]"

The breakage from r12-7804 (in WebKit, particularly) is more of a can of
worms than I think we can address in GCC 12, so let's return to the GCC 11
status quo for now and try again in stage 1.

I think the change was correct for the current standard, but the standard
needs a fix in this area; this is CWG issue 2335.

PR c++/96645

This reverts commits r12-7804 and r12-7929.

jit: further doc fixes

Further jit doc fixes, which fix links to
gcc_jit_function_type_get_param_type and gcc_jit_struct_get_field.

gcc/jit/ChangeLog:
* docs/topics/expressions.rst: Fix formatting.
* docs/topics/types.rst: Likewise.
* docs/_build/texinfo/libgccjit.texi: Regenerate

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

jit: Update docs

Update docs concerning linking and fix formatting errors.

gcc/jit/ChangeLog:
* docs/topics/compatibility.rst: Add 19 tag
* docs/topics/compilation.rst: Linking
* docs/topics/contexts.rst: Linking example
* docs/topics/expressions.rst: Fix formatting and dropped 's'

Signed-off-by: Petter Tomner 2022-02-19 <tomner@kth.se>

libstdc++: Implement std::unreachable() for C++23 (P0627R6)

This defines std::unreachable as an assertion for debug mode, a trap
when _GLIBCXX_ASSERTIONS is defined, and __builtin_unreachable()
otherwise.

The reason for only using __builtin_trap() in the second case is to
avoid the overhead of setting up a call to __glibcxx_assert_fail that
should never happen.

UBsan can detect if __builtin_unreachable() is executed, so if a feature
test macro for that sanitizer is added, we could change just use
__builtin_unreachable() when the sanitizer is enabled.

While thinking about what the debug assertion failure should print, I
noticed that the __glibcxx_assert_fail function doesn't check for null
pointers. This adds a check so we don't try to print them if null.

libstdc++-v3/ChangeLog:

* include/std/utility (unreachable): Define for C++23.
* include/std/version (__cpp_lib_unreachable): Define.
* src/c++11/debug.cc (__glibcxx_assert_fail): Check for valid
arguments. Handle only the function being given.
* testsuite/20_util/unreachable/1.cc: New test.
* testsuite/20_util/unreachable/version.cc: New test.

libstdc++: Fix mismatched noexcept-specifiers in Filesystem TS

The copy_file fix should have been part of r12-7063-gda72e0fd20f87b.

The path::begin() fix should have been part of r12-3930-gf2b7f56a15d9cb.
Thanks to Timm Bäder for reporting this one.

libstdc++-v3/ChangeLog:

* include/experimental/bits/fs_fwd.h (copy_file): Remove
incorrect noexcept from declaration.
* include/experimental/bits/fs_path.h (path::begin, path::end):
Add noexcept to declarations, to match definitions.

[libgomp, testsuite, nvptx] Limit recursion in declare_target-{1,2}.f90

When running testcases libgomp.fortran/examples-4/declare_target-{1,2}.f90 on
an RTX A2000 (sm_86) with driver 510.60.02 and with GOMP_NVPTX_JIT=-O0 I run
into:
...
FAIL: libgomp.fortran/examples-4/declare_target-1.f90 -O0 \
  -DGOMP_NVPTX_JIT=-O0 execution test
FAIL: libgomp.fortran/examples-4/declare_target-2.f90 -O0 \
  -DGOMP_NVPTX_JIT=-O0 execution test
...

Fix this by further limiting recursion depth in the test-cases for nvptx.

Furthermore, make the recursion depth limiting nvptx-specific.

Tested on x86_64 with nvptx accelerator.

libgomp/ChangeLog:

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

* testsuite/libgomp.fortran/examples-4/declare_target-1.f90: Define
and use REC_DEPTH.
* testsuite/libgomp.fortran/examples-4/declare_target-2.f90: Same.

[libgomp, testsuite, nvptx] Fix dg-output test in vector-length-128-7.c

When running test-case libgomp.oacc-c-c++-common/vector-length-128-7.c on an
RTX A2000 (sm_86) with driver 510.60.02 I run into:
...
FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/vector-length-128-7.c \
  -DACC_DEVICE_TYPE_nvidia=1 -DACC_MEM_SHARED=0 -foffload=nvptx-none  -O0  \
  output pattern test
...

The failing check verifies the launch dimensions:
...
/* { dg-output "nvptx_exec: kernel main\\\$_omp_fn\\\$0: \
                launch gangs=1, workers=8, vectors=128" } */
...
which fails because (as we can see with GOMP_DEBUG=1) the actual num_workers
is 6:
...
  nvptx_exec: kernel main$_omp_fn$0: launch gangs=1, workers=6, vectors=128
...

This is due to the result of cuOccupancyMaxPotentialBlockSize (which suggests
'a launch configuration with reasonable occupancy') printed just before:
...
cuOccupancyMaxPotentialBlockSize: grid = 52, block = 768
...
[ Note: 6 * 128 == 768. ]

Fix this by updating the check to allow num_workers in the range 1 to 8.

Tested on x86_64 with nvptx accelerator.

libgomp/ChangeLog:

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

* testsuite/libgomp.oacc-c-c++-common/vector-length-128-7.c: Fix
num_workers check.

libstdc++: Fix filenames in Doxygen @file comments

Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
libstdc++-v3/ChangeLog:

* include/bits/fs_ops.h: Fix filename in Doxygen comment.
* include/experimental/bits/fs_ops.h: Likewise.

phiopt: Improve value_replacement [PR104645]

The following patch fixes the P1 regression by reusing existing
value_replacement code.  That function already has code to
handle simple preparation statements (casts, and +,&,|,^ binary
assignments) before a final binary assignment (which can be
much wider range of ops).  When we have e.g.
      if (y_3(D) == 0)
        goto <bb 4>;
      else
        goto <bb 3>;
     <bb 3>:
      y_4 = y_3(D) & 31;
      _1 = (int) y_4;
      _6 = x_5(D) r<< _1;
     <bb 4>:
      # _2 = PHI <x_5(D)(2), _6(3)>
the preparation statements y_4 = y_3(D) & 31; and
_1 = (int) y_4; are handled by constant evaluation, passing through
y_3(D) = 0 initially and propagating that through the assignments
with checking that UB isn't invoked.  But the final
_6 = x_5(D) r<< _1; assign is handled differently, either through
neutral_element_p or absorbing_element_p.
In the first function below we now have:
  <bb 2> [local count: 1073741824]:
  if (i_2(D) != 0)
    goto <bb 3>; [50.00%]
  else
    goto <bb 4>; [50.00%]

  <bb 3> [local count: 536870913]:
  _3 = i_2(D) & 1;
  iftmp.0_4 = (int) _3;

  <bb 4> [local count: 1073741824]:
  # iftmp.0_1 = PHI <iftmp.0_4(3), 0(2)>
where in GCC 11 we had:
  <bb 2> :
  if (i_3(D) != 0)
    goto <bb 3>; [INV]
  else
    goto <bb 4>; [INV]

  <bb 3> :
  i.1_1 = (int) i_3(D);
  iftmp.0_5 = i.1_1 & 1;

  <bb 4> :
  # iftmp.0_2 = PHI <iftmp.0_5(3), 0(2)>
Current value_replacement can handle the latter as the last
stmt of middle_bb is a binary op that in this case satisfies
absorbing_element_p.
But the former we can't handle, as the last stmt in middle_bb
is a cast.

The patch makes it work in that case by pretending all of middle_bb
are the preparation statements and there is no binary assign at the
end, so everything is handled through the constant evaluation.
We simply set at the start of middle_bb the lhs of comparison
virtually to the rhs, propagate it through and at the end
see if virtually the arg0 of the PHI is equal to arg1 of it.

For GCC 13, I think we just should throw away all the neutral/absorbing
element stuff and do the constant evaluation of the whole middle_bb
and handle that way all the ops we currently handle in neutral/absorbing
element.

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

PR tree-optimization/104645
* tree-ssa-phiopt.cc (value_replacement): If assign has
CONVERT_EXPR_CODE_P rhs_code, treat it like a preparation
statement with constant evaluation.

* gcc.dg/tree-ssa/pr104645.c: New test.

testsuite: Add further zero size elt passing tests [PR102024]

As discussed in PR102024, zero width bitfields might not be the only ones
causing ABI issues at least on mips, zero size arrays or (in C only) zero
sized (empty) structures can be problematic too.

The following patch adds some coverage for it too.

Tested on x86_64-linux with
make check-gcc check-g++ RUNTESTFLAGS='ALT_CC_UNDER_TEST=gcc ALT_CXX_UNDER_TEST=g++ --target_board=unix\{-m32,-m64\} compat.exp=pr102024*'
make check-gcc check-g++ RUNTESTFLAGS='ALT_CC_UNDER_TEST=clang ALT_CXX_UNDER_TEST=clang++ --target_board=unix\{-m32,-m64\} compat.exp=pr102024*'
with gcc/g++ 10.3 and clang 11.  Everything but (expectedly)
FAIL: gcc.dg/compat/pr102024 c_compat_x_tst.o-c_compat_y_alt.o execute
FAIL: gcc.dg/compat/pr102024 c_compat_x_alt.o-c_compat_y_tst.o execute
for -m64 ALT_CC_UNDER_TEST=gcc passes.

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

PR target/102024
* gcc.dg/compat/pr102024_test.h: Add further tests with zero sized
structures and arrays.
* g++.dg/compat/pr102024_test.h: Add further tests with zero sized
arrays.

[nvptx, testsuite] Fix gcc.target/nvptx/alias-*.c on sm_80

When running test-cases gcc.target/nvptx/alias-*.c on target board
nvptx-none-run/-misa=sm_80 we run into fails because the test-cases add
-mptx=6.3, which doesn't support sm_80.

Fix this by only adding -mptx=6.3 if necessary, and simplify the test-cases by
using ptx_alias feature abstractions:
...
/* { dg-do run { target runtime_ptx_alias } } */
/* { dg-add-options ptx_alias } */
...

Tested on nvptx.

gcc/testsuite/ChangeLog:

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

* gcc.target/nvptx/nvptx.exp
(check_effective_target_runtime_ptx_isa_version_6_3): Rename and
generalize to ...
(check_effective_target_runtime_ptx_isa_version_at_least): .. this.
(check_effective_target_default_ptx_isa_version_at_least)
(check_effective_target_runtime_ptx_alias, add_options_for_ptx_alias):
New proc.
* gcc.target/nvptx/alias-1.c: Use "target runtime_ptx_alias" and
"dg-add-options ptx_alias".
* gcc.target/nvptx/alias-2.c: Same.
* gcc.target/nvptx/alias-3.c: Same.
* gcc.target/nvptx/alias-4.c: Same.

MIPS: IPL is 8bit in Cause and Status registers if TARGET_MCU

If MIPS MCU extension is enable, the IPL section in Cause and Status
registers has been expand to 8bit instead of 6bit.

In Cause: the bits are 10-17.
In Status: the bits are 10-16 and 18.

MD00834-2B-MUCON-AFP-01.03.pdf: P49 and P61.

gcc/ChangeLog:

* config/mips/mips.cc (mips_expand_prologue):
  IPL is 8bit for MCU ASE.

MAINTAINERS: Update my email address

Update my email address in the MAINTAINERS file.

2022-04-01  Qian Jianhua  <qianjh@fujitsu.com>

ChangeLog:

* MAINTAINERS: Update my email address.

Test for linking for arm/size-optimization-ieee-[123].c

These tests require a target that supports arm soft-float.  The
problem is that the test checks for compile-time soft-float support,
but they may hit a problem when the linker complains that it can't
combine the testcase's object file with hard-float init files and
target system libraries.

I don't see that the tests actually require linking, and they could be
simplified to dg-do assemble, but I figured a link test for soft-float
support could be useful, so I added that, and adjusted the tests to
require it instead.

for  gcc/testsuite/ChangeLog

* lib/target-supports.exp
(check_effective_target_arm_soft_ok_link): New.
* gcc.target/arm/size-optimization-ieee-1.c: Use it.
* gcc.target/arm/size-optimization-ieee-2.c: Likewise.
* gcc.target/arm/size-optimization-ieee-3.c: Likewise.

Daily bump.