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.

rs6000: Fix some missing built-in attributes [PR104004]

PR104004 caught some misses on my part in converting to the new built-in
function infrastructure.  In particular, I forgot to mark all of the "nosoft"
built-ins, and one of those should also have been marked "no32bit".

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

gcc/
PR target/104004
* config/rs6000/rs6000-builtins.def (MFFSL): Mark nosoft.
(MTFSB0): Likewise.
(MTFSB1): Likewise.
(SET_FPSCR_RN): Likewise.
(SET_FPSCR_DRN): Mark nosoft and no32bit.

runtime: support PPC32 MUSL register access

Based on patch by Sören Tempel.

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

options: Clarifications around option definition records' help texts

gcc/
* doc/options.texi (Option file format): Clarifications around
option definition records' help texts.

options: Fix "Multiple different help strings" error diagnostic

This currently causes a confusing litany, for example:

    options.cc:3245:2: error: #error Multiple different help strings for Wunused-result:
     #error Multiple different help strings for Wunused-result:
      ^
    options.cc:3246:2: error: 'Warn' was not declared in this scope
      Warn if a caller of a function, marked with attribute warn_unused_result, does not use its return value.
      ^
    options.cc:3246:7: error: expected '}' before 'if'
      Warn if a caller of a function, marked with attribute warn_unused_result, does not use its return value.
           ^
    options.cc:3246:7: error: expected ',' or ';' before 'if'
    options.cc:3256:54: error: expected unqualified-id before ',' token
         (unsigned short) -1, 0, CLVC_INTEGER, 0, -1, -1 },
                                                          ^
    [going on for several thousands of lines]

Fixed:

    options.cc:3245:2: error: #error Multiple different help strings for Wunused-result:
     #error Multiple different help strings for Wunused-result:
      ^
    options.cc:3246:2: error: #error Warn if a caller of a function, marked with attribute warn_unused_result, does not use its return value.
     #error   Warn if a caller of a function, marked with attribute warn_unused_result, does not use its return value.
      ^
    options.cc:3247:2: error: #error TEST.
     #error   TEST.
      ^

Fix-up for r187437/commit 71caddc5568f59a5990f39226f60979a7fe953ef
"optc-gen.awk: Error instead of warning for conflicting help".

gcc/
* optc-gen.awk <END>: Fix "Multiple different help strings" error
diagnostic.

contrib: Fix up spelling of loongarch-str.h dependency [PR105114]

As found by Joseph, the dependency of
gcc/config/loongarch/loongarch-str.h is spelled incorrectly,
it should be
gcc/config/loongarch/genopts/loongarch-strings
but was using
gcc/config/loongarch/genopts/loongarch-string

2022-03-31  Jakub Jelinek  <jakub@redhat.com>
    Joseph Myers  <joseph@codesourcery.com>

PR other/105114
* gcc_update: Fix up spelling of
gcc/config/loongarch/genopts/loongarch-strings dependency.

aarch64: Implement determine_suggested_unroll_factor

This patch implements the costing function determine_suggested_unroll_factor
for aarch64.
It determines the unrolling factor by dividing the number of X operations we
can do per cycle by the number of X operations, taking this information from
the vec_ops analysis during vector costing and the available issue_info
information.
We multiply the dividend by a potential reduction_latency, to improve our
pipeline utilization if we are stalled waiting on a particular reduction
operation.

gcc/ChangeLog:

* config/aarch64/aarch64.cc (aarch64_vector_costs): Define
determine_suggested_unroll_factor and m_has_avg.
(determine_suggested_unroll_factor): New function.
(aarch64_vector_costs::add_stmt_cost): Check for a qualifying pattern
to set m_nosve_pattern.
(aarch64_vector_costs::finish_costs): Use
determine_suggested_unroll_factor.
* config/aarch64/aarch64.opt (aarch64-vect-unroll-limit): New.
* doc/invoke.texi: (aarch64-vect-unroll-limit): Document new option.

ipa: Careful processing ANCESTOR jump functions and NULL pointers (PR 103083)

IPA_JF_ANCESTOR jump functions are constructed also when the formal
parameter of the caller is first checked whether it is NULL and left
as it is if it is NULL, to accommodate C++ casts to an ancestor class.

The jump function type was invented for devirtualization and IPA-CP
propagation of tree constants is also careful to apply it only to
existing DECLs(*) but as PR 103083 shows, the part propagating "known
bits" was not careful about this, which can lead to miscompilations.

This patch introduces a flag to the ancestor jump functions which
tells whether a NULL-check was elided when creating it and makes the
bits propagation behave accordingly, masking any bits otherwise would
be known to be one.  This should safely preserve alignment info, which
is the primary ifnormation that we keep in bits for pointers.

(*) There still may remain problems when a DECL resides on address
zero (with -fno-delete-null-pointer-checks ...I hope it cannot happen
otherwise).  I am looking into that now but I think it will be easier
for everyone if I do so in a follow-up patch.

gcc/ChangeLog:

2022-02-11  Martin Jambor  <mjambor@suse.cz>

PR ipa/103083
* ipa-prop.h (ipa_ancestor_jf_data): New flag keep_null;
(ipa_get_jf_ancestor_keep_null): New function.
* ipa-prop.cc (ipa_set_ancestor_jf): Initialize keep_null field of the
ancestor function.
(compute_complex_assign_jump_func): Pass false to keep_null
parameter of ipa_set_ancestor_jf.
(compute_complex_ancestor_jump_func): Pass true to keep_null
parameter of ipa_set_ancestor_jf.
(update_jump_functions_after_inlining): Carry over keep_null from the
original ancestor jump-function or merge them.
(ipa_write_jump_function): Stream keep_null flag.
(ipa_read_jump_function): Likewise.
(ipa_print_node_jump_functions_for_edge): Print the new flag.
* ipa-cp.cc (class ipcp_bits_lattice): Make various getters const.  New
member function known_nonzero_p.
(ipcp_bits_lattice::known_nonzero_p): New.
(ipcp_bits_lattice::meet_with_1): New parameter drop_all_ones,
observe it.
(ipcp_bits_lattice::meet_with): Likewise.
(propagate_bits_across_jump_function): Simplify.  Pass true in
drop_all_ones when it is necessary.
(propagate_aggs_across_jump_function): Take care of keep_null
flag.
(ipa_get_jf_ancestor_result): Propagate NULL accross keep_null
jump functions.

gcc/testsuite/ChangeLog:

2021-11-25  Martin Jambor  <mjambor@suse.cz>

* gcc.dg/ipa/pr103083-1.c: New test.
* gcc.dg/ipa/pr103083-2.c: Likewise.

libstdc++: Add comment about memalign requirements

The memalign man page on Solaris and QNX lists an additional requirement
for the alignment value that is not present in all implementation of
that non-standard function. For both those targets we should actually be
using posix_memalign anyway, so it doesn't matter. This just adds a
comment making note of that fact.

libstdc++-v3/ChangeLog:

* libsupc++/new_opa.cc (aligned_alloc): Add comment.

ipa-cp: Do not create clones for values outside known value range (PR 102513)

PR 102513 shows we emit bogus array access warnings when IPA-CP
creates clones specialized for values which it deduces from arithmetic
jump functions describing self-recursive calls.  Those can however be
avoided if we consult the IPA-VR information that the same pass also
has.

The patch below does that at the stage when normally values are only
examined for profitability.  It would be better not to create lattices
describing such bogus values in the first place, however that presents
an ordering problem, the pass currently propagates all information,
and so both constants and VR, in no particular order when processing
SCCs, and so this approach seemed much simpler.

I plan to rearrange the pass so that it clones in multiple passes over
the call graph (or rather the lattice dependence graph) and it feels
natural to only do propagation for these kinds of recursion in the
second or later passes, which would fix the issue more elegantly.

gcc/ChangeLog:

2022-02-14  Martin Jambor  <mjambor@suse.cz>

PR ipa/102513
* ipa-cp.cc (decide_whether_version_node): Skip scalar values
which do not fit the known value_range.

gcc/testsuite/ChangeLog:

2022-02-14  Martin Jambor  <mjambor@suse.cz>

PR ipa/102513
* gcc.dg/ipa/pr102513.c: New test.

ipa: Create LOAD references when necessary during inlining (PR 103171)

in r12-2523-g13586172d0b70c ipa-prop tracking of jump functions during
inlining got the ability to remove ADDR references when inlining
discovered that they were not necessary or turn them into LOAD
references when we know that what was a function call argument passed
by reference will end up as a load (one or more).

Unfortunately, the code only creates the LOAD references when
replacing removed ADDR references and PR 103171 showed that with some
ordering of inlining, we need to add the LOAD reference before we know
we can remove the ADDR one - or the reference will be lost, leading to
link errors or even ICEs.

Specifically in testcase gcc.dg/lto/pr103171_1.c added in this patch,
if foo() is inlined to entry(), we need to create the LOAD reference
so that when later bar() is inlined into foo() and we discover that
the paameter is unused, we can remove the ADDR reference and still
keep the varaible around for the load.

Martin

gcc/ChangeLog:

2022-01-28  Martin Jambor  <mjambor@suse.cz>

PR ipa/103171
* ipa-prop.cc (propagate_controlled_uses): Add a LOAD reference
always when an ADDR_EXPR constant is known to reach a load because
of inlining, not just when removing an ADDR reference.

gcc/testsuite/ChangeLog:

2022-01-28  Martin Jambor  <mjambor@suse.cz>

PR ipa/103171
* gcc.dg/ipa/remref-6.c: Adjust dump scan string.
* gcc.dg/ipa/remref-7.c: New test.
* gcc.dg/lto/pr103171_0.c: New test.
* gcc.dg/lto/pr103171_1.c: Likewise.

[nvptx, testsuite] Fix typo in gcc.target/nvptx/march.c

The dg-options line in gcc.target/nvptx/march.c:
...
/* { dg-options "-march=sm_30"} */
...
currently doesn't have any effect because it's missing a space between '"' and
'}'.

Fix this by adding the missing space.

Tested on nvptx.

gcc/testsuite/ChangeLog:

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

* gcc.target/nvptx/march.c: Add missing space in dg-options line.

tree-optimization/105109 - bogus uninit diagnostic with _Complex

When update_address_taken rewrites a _Complex into SSA it changes
stores to real/imaginary parts to loads of the other component and
a COMPLEX_EXPR.  That matches what gimplification does but it misses
suppression of diagnostics for the load of the other component.
The following patch adds that, syncing up gimplification and
update_address_taken behavior.

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

PR tree-optimization/105109
* tree-ssa.cc (execute_update_addresses_taken): Suppress
diagnostics on the load of the other complex component.

* gcc.dg/uninit-pr105109.c: New testcase.

[nvptx] Fix ASM_SPEC workaround for sm_30

Newer versions of CUDA no longer support sm_30, and nvptx-tools as
currently doesn't handle that gracefully when verifying
( https://github.com/MentorEmbedded/nvptx-tools/issues/30 ).

There's a --no-verify work-around in place in ASM_SPEC, but that one doesn't
work when using -Wa,--verify on the command line.

Use a more robust workaround: verify using sm_35 when misa=sm_30 is specified
(either implicitly or explicitly).

Tested on nvptx.

gcc/ChangeLog:

2022-03-30  Tom de Vries  <tdevries@suse.de>

* config/nvptx/nvptx.h (ASM_SPEC): Use "-m sm_35" for -misa=sm_30.

rtl-optimization/105091 - wrong DSE with missed TREE_ADDRESSABLE

When expanding an aggregate copy into a memcpy call RTL expansion
uses mark_addressable to ensure the base object is addressable but
that function doesn't handle TARGET_MEM_REF bases.  Fixed as follows.

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

PR rtl-optimization/105091
* gimple-expr.cc (mark_addressable): Handle TARGET_MEM_REF
bases.

Revert "gimple: allow more folding of memcpy [PR102125]"

This reverts commit 5f6a6c91d7c592cb49f7c519f289777eac09bb74.

gcov: Reword comment for gcov_read_string()

gcc/

* gcov-io.cc (gcov_read_string): Reword documentation comment.

c++: parse trivial DMI immediately [PR96645]

The recent change to reject __is_constructible for nested classes with DMI
is, unsurprisingly, breaking some code.  Let's allow simple cases by
immediately parsing DMI that do no name lookup; then being in complete class
scope makes no difference.

PR c++/96645

gcc/cp/ChangeLog:

* parser.cc (cp_parser_early_parsing_nsdmi): New.
(cp_parser_member_declaration): Call it.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/nsdmi10.C: Now OK.
* g++.dg/ext/is_constructible3.C: Likewise.
* g++.dg/ext/is_constructible7.C: Likewise.

Daily bump.

Fortran: NULL pointer dereference checking arguments to ASSOCIATED intrinsic

gcc/fortran/ChangeLog:

PR fortran/100892
* check.cc (gfc_check_associated): Avoid NULL pointer dereference.

gcc/testsuite/ChangeLog:

PR fortran/100892
* gfortran.dg/associated_target_8.f90: New test.

Update gcc hr.po

* hr.po: Update.

rs6000: vec_neg built-ins wrongly require POWER8

As the subject states.  Fixing this is accomplished by moving the built-ins
to the correct stanzas, [altivec] and [vsx].

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

gcc/
* config/rs6000/rs6000-builtins.def (NEG_V16QI): Move to [altivec]
stanza.
(NEG_V4SF): Likewise.
(NEG_V4SI): Likewise.
(NEG_V8HI): Likewise.
(NEG_V2DF): Move to [vsx] stanza.
(NEG_V2DI): Likewise.

[PR105032] LRA: modify loop condition to find reload insns for hard reg splitting

When trying to split hard reg live range to assign hard reg to a reload
pseudo, LRA searches for reload insns of the reload pseudo
assuming a specific order of the reload insns.  This order is violated if
reload involved in inheritance transformation. In such case, the loop used
for reload insn searching can become infinite.  The patch fixes this.

gcc/ChangeLog:

PR middle-end/105032
* lra-assigns.cc (find_reload_regno_insns): Modify loop condition.

gcc/testsuite/ChangeLog:

PR middle-end/105032
* gcc.target/i386/pr105032.c: New.

Revert "testsuite: Change pr80334.C testcase to dg-do compile [PR102772]"

This reverts commit 6a777ceb0e975f0efc823d2d82e676346f068151.

c-family: ICE with -Wconversion and A ?: B [PR101030]

This patch fixes a crash in conversion_warning on a null expression.
It is null because the testcase uses the GNU A ?: B extension.  We
could also use op0 instead of op1 in this case, but it doesn't seem
to be necessary.

PR c++/101030

gcc/c-family/ChangeLog:

* c-warn.cc (conversion_warning) <case COND_EXPR>: Don't call
conversion_warning when OP1 is null.

gcc/testsuite/ChangeLog:

* g++.dg/ext/cond5.C: New test.

c++: ICE with failed __is_constructible constraint [PR100474]

Here we're crashing when diagnosing an unsatisfied __is_constructible
constraint because diagnose_trait_expr doesn't recognize this trait
(along with a bunch of other traits).  Fix this by adding handling for
all remaining traits and removing the default case so that when adding a
new trait we'll get a warning that diagnose_trait_expr needs to handle it.

PR c++/100474

gcc/cp/ChangeLog:

* constraint.cc (diagnose_trait_expr): Handle all remaining
traits appropriately.  Remove default case.

gcc/testsuite/ChangeLog:

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

testsuite: Change pr80334.C testcase to dg-do compile [PR102772]

The testcase has UB at runtime, placement new shouldn't construct
an object with certain alignment requirements into an unaligned buffer.

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

PR tree-optimization/80334
PR target/102772
* g++.dg/torture/pr80334.C: Change from dg-do run to dg-do compile.

c++: ICE with aggregate assignment and DMI [PR104583]

The attached 93280 test no longer ICEs but looks like it was never added to the
testsuite.  The 104583 test, modified so that it closely resembles 93280, still
ICEs.

The problem is that in 104583 we have a value-init from {} (the line A a{};),
so this code in convert_like_internal

 7960         /* If we're initializing from {}, it's value-initialization.  */
 7961         if (BRACE_ENCLOSED_INITIALIZER_P (expr)
 7962             && CONSTRUCTOR_NELTS (expr) == 0
 7963             && TYPE_HAS_DEFAULT_CONSTRUCTOR (totype)
 7964             && !processing_template_decl)
 7965           {
 7966             bool direct = CONSTRUCTOR_IS_DIRECT_INIT (expr);
...
 7974                 TARGET_EXPR_DIRECT_INIT_P (expr) = direct;

sets TARGET_EXPR_DIRECT_INIT_P.  This does not happen in 93280 where we
initialize from {0}.

In 104583, when gimplifying, the d = {}; line, we have

d = {.a=TARGET_EXPR <D.2474, <<< Unknown tree: aggr_init_expr
  4
  __ct_comp
  D.2474
  (struct A *) <<< Unknown tree: void_cst >>> >>>>}

where the TARGET_EXPR is the one with TARGET_EXPR_DIRECT_INIT_P set.  In
gimplify_init_ctor_preeval we do

 4724       FOR_EACH_VEC_SAFE_ELT (v, ix, ce)
 4725         gimplify_init_ctor_preeval (&ce->value, pre_p, post_p, data);

so we gimplify the TARGET_EXPR, crashing at

 744     case TARGET_EXPR:
 745       /* A TARGET_EXPR that expresses direct-initialization should have
been
 746          elided by cp_gimplify_init_expr.  */
 747       gcc_checking_assert (!TARGET_EXPR_DIRECT_INIT_P (*expr_p));

but there is no INIT_EXPR so cp_gimplify_init_expr was never called!

Now, the fix for c++/93280
<https://gcc.gnu.org/pipermail/gcc-patches/2020-January/538414.html>
says "let's only set TARGET_EXPR_DIRECT_INIT_P when we're using the DMI in
a constructor." and the comment talks about the full initialization.  Is
is accurate to say that our TARGET_EXPR does not represent the full
initialization, because it only initializes the 'a' subobject?  If so,
then maybe get_nsdmi should clear TARGET_EXPR_DIRECT_INIT_P when in_ctor
is false.

I've compared the 93280.s and 104583.s files, they differ only in one
movl $0, so there are no extra calls and similar.

PR c++/93280
PR c++/104583

gcc/cp/ChangeLog:

* init.cc (get_nsdmi): Set TARGET_EXPR_DIRECT_INIT_P to in_ctor.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/nsdmi-list7.C: New test.
* g++.dg/cpp0x/nsdmi-list8.C: New test.

[nvptx, doc] Document predefined macros at march and mptx

Document predefined macros:
- __PTX_SM__ ,
- __PTX_ISA_VERSION_MAJOR__ and
- __PTX_ISA_VERSION_MINOR__ .

gcc/ChangeLog:

2022-03-29  Tom de Vries  <tdevries@suse.de>

* doc/invoke.texi (march): Document __PTX_SM__.
 (mptx): Document __PTX_ISA_VERSION_MAJOR__ and
 __PTX_ISA_VERSION_MINOR__.

Co-Authored-By: Tobias Burnus <tobias@codesourcery.com>

ubsan: Fix ICE due to -fsanitize=object-size [PR105093]

The following testcase ICEs, because for a volatile X & RESULT_DECL
ubsan wants to take address of that reference.  instrument_object_size
is called with x, so the base is equal to the access and the var
is automatic, so there is no risk of an out of bounds access for it.
Normally we wouldn't instrument those because we fold address of the
t - address of inner to 0, add constant size of the decl and it is
equal to what __builtin_object_size computes.  But the volatile
results in the subtraction not being folded.

The first hunk fixes it by punting if we access the whole automatic
decl, so that even volatile won't cause a problem.
The second hunk (not strictly needed for this testcase) is similar
to what has been added to asan.cc recently, if we actually take
address of a decl and keep it in the IL, we better mark it addressable.

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

PR sanitizer/105093
* ubsan.cc (instrument_object_size): If t is equal to inner and
is a decl other than global var, punt.  When emitting call to
UBSAN_OBJECT_SIZE ifn, make sure base is addressable.

* g++.dg/ubsan/pr105093.C: New test.

store-merging: Avoid ICEs on roughly ~0ULL/8 sized stores [PR105094]

On the following testcase on 64-bit targets, store-merging sees
a MEM_REF store from {} ctor with "negative" bitsize where bitoff + bitsize
wraps around to very small end offset.  This later confuses the code
so that it allocates just a few bytes of memory but fills in huge amounts of
it.  Later on there is a param_store_merging_max_size size check but due to
the wrap-around we pass that.

The following patch punts on such large bitsizes.

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

PR tree-optimization/105094
* gimple-ssa-store-merging.cc (mem_valid_for_store_merging): Punt if
bitsize <= 0 rather than just == 0.

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

openmp: Ensure DECL_CONTEXT of OpenMP iterators in templates [PR105092]

cp_parser_omp_iterators does:
      DECL_ARTIFICIAL (iter_var) = 1;
      DECL_CONTEXT (iter_var) = current_function_decl;
      pushdecl (iter_var);
on the newly created iterator vars, but when we instantiate templates
containing them, we just tsubst_decl them (which apparently for
automatic vars clears DECL_CONTEXT with a comment that pushdecl should
be called on them later).
The result is that we have automatic vars in the IL which have NULL
DECL_CONTEXT and the analyzer is upset about those.

Fixed by setting DECL_CONTEXT and calling pushdecl during the instantiation.

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

PR c++/105092
* pt.cc (tsubst_omp_clause_decl): When handling iterators, set
DECL_CONTEXT of the iterator var to current_function_decl and
call pushdecl.

* g++.dg/gomp/pr105092.C: New test.