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.

[nvptx, doc] Update misa and mptx, add march and march-map

Update nvptx documentation:
- Use meaningful terms: "PTX ISA target architecture" and "PTX ISA version".
- Remove invalid claim that "ISA strings must be lower-case".
- Add missing sm_xx entries.
- Fix misa default.
- Add march, copying misa doc.
- Declare misa an march alias.
- Add march-map.
- Fix "for given the specified" typo.

gcc/ChangeLog:

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

* doc/invoke.texi (misa, mptx): Update.
(march, march-map): Add.

c++: Fox template-introduction tentative parsing in class bodies clear colon_corrects_to_scope_p [PR105061]

The concepts support (in particular template introductions from concepts TS)
broke the following testcase, valid unnamed bitfields with dependent
types (or even just typedefs) were diagnosed as typos (: instead of correct
::) in template introduction during their tentative parsing.
The following patch fixes that by not doing this : to :: correction when
member_p is true.

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

PR c++/105061
* parser.cc (cp_parser_template_introduction): If member_p, temporarily
clear parser->colon_corrects_to_scope_p around tentative parsing of
nested name specifier.

* g++.dg/concepts/pr105061.C: New test.

options: Improve 'LangEnabledBy' option property diagnostics

No changes in generated files.

gcc/
* opt-functions.awk (n_args): New function.
(lang_enabled_by): Merge function into...
* optc-gen.awk <END>: ... sole user here.
Improve diagnostics.

options, '-Wc++[...]-extensions': Remove undefined one-argument 'LangEnabledBy' option properties

A one-argument form of the 'LangEnabledBy' option property isn't defined,
and effectively appears to be a no-op.  Removing these only changes
'build-gcc/gcc/optionlist' accordingly, but no other generated files.

Clean-up for commit ee336ecb2a7161bc28f6c5343d97870a8d15e177
"c++: Add new warning options for C++ language mismatches".

gcc/c-family/
* c.opt (Wc++11-extensions, Wc++14-extensions, Wc++17-extensions)
(Wc++20-extensions, Wc++23-extensions): Remove 'LangEnabledBy'
option properties.

options: Remove 'gcc/c-family/c.opt:Wuse-after-free' option definition record

A one-argument form of the 'LangEnabledBy' option property isn't defined,
and effectively appears to be a no-op.  Removing that one, the
'gcc/c-family/c.opt:Wuse-after-free' option definition record becomes
empty, and doesn't add anything over 'gcc/common.opt:Wuse-after-free', and
may thus be removed entirely.  This only changes 'build-gcc/gcc/optionlist'
accordingly, but no other generated files.

Clean-up after recent commit 671a283636de75f7ed638ee6b01ed2d44361b8b6
"Add -Wuse-after-free [PR80532]".

gcc/c-family/
* c.opt (Wuse-after-free): Remove.

options: Remove 'gcc/c-family/c.opt:Warray-bounds' option definition record

A one-argument form of the 'LangEnabledBy' option property isn't defined,
and effectively appears to be a no-op.  Removing that one, the
'gcc/c-family/c.opt:Warray-bounds' option definition record becomes empty,
and doesn't add anything over 'gcc/common.opt:Warray-bounds', and may thus
be removed entirely.  This only changes 'build-gcc/gcc/optionlist'
accordingly, but no other generated files.

Clean-up after r262912/commit 0d7f90652080c42cddca6f9b68f6895218c70880
"PR middle-end/82063 - issues with arguments enabled by -Wall".

gcc/c-family/
* c.opt (Warray-bounds): Remove.

analyzer/strndup-1.c: skip on *-*-vxworks*

Add vxworks to the set of operating systems whose C libraries don't
support strndup.

for  gcc/testsuite/ChangeLog

* gcc.dg/analyzer/strndup-1.c: Add *-*-vxworks* to no-strndup
in libc.

gcc.dg/weak/typeof-2: arm may use constant pool

Some ARM configurations, such as with -mlong-calls, load the call
target from the constant pool, breaking the expectation of the test as
on several other targets.

for  gcc/testsuite/ChangeLog

* gcc.dg/weak/typeof-2.c: Add arm*-*-* to targets that may
place the call target in a constant pool.

Daily bump.

analyzer: skip constant pool in -fdump-analyzer-untracked [PR testsuite/105085]

In r12-7809-g5f6197d7c197f9 I added -fdump-analyzer-untracked as support
for DejaGnu testing of an optimization of -fanalyzer,
PR analyzer/104954.

PR testsuite/105085 notes testsuite failures of the form:
  FAIL: gcc.dg/analyzer/untracked-1.c (test for excess errors)
  Excess errors:
  cc1: warning: track '*.LC1': yes
where these warnings are emitted on some targets where the test
causes labelled constants to be created in the constant pool.

We probably ought not to be tracking the values of such decls in the
store, given that they're meant to be constant, and I attempted various
fixes to make the "should we track this decl" logic smarter, but given
that we're in stage 4, the simplest fix seems to be for
-fdump-analyzer-untracked to skip such decls in its output, to minimize
test output differences between targets.

gcc/analyzer/ChangeLog:
PR testsuite/105085
* region-model-manager.cc (dump_untracked_region): Skip decls in
the constant pool.

gcc/testsuite/ChangeLog:
PR testsuite/105085
* gcc.dg/analyzer/untracked-1.c: Add further test coverage.

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

Fortran: avoid NULL pointer dereference checking elemental procedure args

gcc/fortran/ChangeLog:

PR fortran/104571
* resolve.cc (resolve_elemental_actual): Avoid NULL pointer
dereference.

gcc/testsuite/ChangeLog:

PR fortran/104571
* gfortran.dg/pr104571.f90: New test.

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

testsuite: Allow setting gpp_std_list in configuration files

This allows the gpp_std_list variable to be set in ~/.dejagnurc instead
of using the GXX_TESTSUITE_STDS environment variable.  This is
consistent with how other defaults such as tool_timeout can be set.

The environment variable can still be used to override the default.

gcc/testsuite/ChangeLog:

* lib/g++-dg.exp: Update comments.
* lib/g++.exp (gpp_std_list): Check for an existing value before
setting it to an empty list.

testsuite: Disable tests for C++23 that depend on std::unexpected

These tests depend on unexpected handlers, which are no longer declared
for C++23 mode. Adjust the target specifier so they don't run.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/noexcept06.C: Disable for C++23.

libstdc++-v3/ChangeLog:

* testsuite/18_support/exception/38732.cc: Disable for C++23.
* testsuite/18_support/headers/exception/synopsis.cc: Likewise.
* testsuite/18_support/unexpected_handler.cc: Likewise.

Update gcc hr.po

* hr.po: Update.

Fortran: character length of pointer assignments in structure constructors

gcc/fortran/ChangeLog:

PR fortran/50549
* resolve.cc (resolve_structure_cons): Reject pointer assignments
of character with different lengths in structure constructor.

gcc/testsuite/ChangeLog:

PR fortran/50549
* gfortran.dg/char_pointer_assign_7.f90: New test.

gimple: Wrong -Wimplicit-fallthrough with if(1) [PR103597]

This patch fixes a wrong -Wimplicit-fallthrough warning for

    case 0:
      if (1)  // wrong may fallthrough
return 0;
    case 1:

which in .gimple looks like

    <D.1981>: // case 0
    if (1 != 0) goto <D.1985>; else goto <D.1986>;
    <D.1985>:
    D.1987 = 0;
    // predicted unlikely by early return (on trees) predictor.
    return D.1987;
    <D.1986>:  // dead
    <D.1982>: // case 1

and the warning thinks that <D.1986>: falls through to <D.1982>:.  It
does not know that <D.1986> is effectively a dead label, only reachable
through fallthrough from previous instructions, never jumped to.  To
that effect, Jakub introduced UNUSED_LABEL_P, which is set on such dead
labels.

collect_fallthrough_labels has code to deal with cases like

    case 2:
      if (e != 10)
i++; // this may fallthru, warn
      else
return 44;
    case 3:

which collects labels that may fall through.  Here it sees the "goto <D.1990>;"
at the end of the then branch and so when the warning reaches

    ...
    <D.1990>: // from if-then
    <D.1984>: // case 3

it knows it should warn about the possible fallthrough.  But an UNUSED_LABEL_P
is not a label that can fallthrough like that, so it should ignore those.

However, we still want to warn about this:

    case 0:
      if (1)
n++; // falls through
    case 1:

so collect_fallthrough_labels needs to return the "n = n + 1;" statement, rather
than the dead label.

Co-authored-by: Jakub Jelinek <jakub@redhat.com>
PR middle-end/103597

gcc/ChangeLog:

* gimplify.cc (collect_fallthrough_labels): Don't push UNUSED_LABEL_Ps
into labels.  Maybe set prev to the statement preceding UNUSED_LABEL_P.
(gimplify_cond_expr): Set UNUSED_LABEL_P.
* tree.h (UNUSED_LABEL_P): New.

gcc/testsuite/ChangeLog:

* c-c++-common/Wimplicit-fallthrough-39.c: New test.

c-family: Add -Wmisleading-indentation testcase [PR71637]

We no longer emit a bogus warning for the below testcase after
r11-3266-g4839de55e2c986.

PR c++/71637

gcc/testsuite/ChangeLog:

* c-c++-common/Wmisleading-indentation-6.c: New test.

Allow vsx_extract_<mode> to use Altivec registers.

I noticed that the vsx_extract_<mode> pattern for V2DImode and V2DFmode
only allowed traditional floating point registers, and it did not allow
Altivec registers.  The original code was written a few years ago when we
used the old register allocator, and support for scalar floating point in
Altivec registers was just being added to GCC.

I have built the spec 2017 benchmark suite With all 4 patches in this
series applied, and compared it to the build with the previous 3 patches
applied.  In addition to the changes from the previous 3 patches, this
patch now changes the code for the following 3 benchmarks (2 floating
point, 1 integer):

bwaves_r, fotonik3d_r, xalancbmk_r

I have built bootstrap versions on the following systems.  There were no
regressions in the runs:

Power9 little endian, --with-cpu=power9
Power10 little endian, --with-cpu=power10
Power8 big endian, --with-cpu=power8 (both 32-bit & 64-bit tests)

2022-03-29   Michael Meissner  <meissner@linux.ibm.com>

gcc/
* config/rs6000/vsx.md (vsx_extract_<mode>): Allow destination to
be any VSX register.

aarch64: correctly handle zero-sized bit-fields in AAPCS64 [PR102024]

On aarch64 the AAPCS64 states that an HFA is determined by the 'shape' of
the object after layout has been completed, so anything that adds no
members and does not cause the layout to be modified should be ignored
for the purposes of determining which registers are used for parameter
passing.

A zero-sized bit-field falls into this category.  This was not handled
correctly for C structs and in G++-11 only handled correctly because
such fields were eliminated early by the front end.

gcc/ChangeLog:

PR target/102024
* config/aarch64/aarch64.cc (aapcs_vfp_sub_candidate): Handle
zero-sized bit-fields.  Detect cases where a warning may be needed.
(aarch64_vfp_is_call_or_return_candidate): Emit a note if a
zero-sized bit-field has caused parameter passing to change.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/aapcs64/test_28.c: New test.

arm: correctly handle zero-sized bit-fields in AAPCS [PR102024]

On arm the AAPCS states that an HFA is determined by the 'shape' of
the object after layout has been completed, so anything that adds no
members and does not cause the layout to be modified should be ignored
for the purposes of determining which registers are used for parameter
passing.

A zero-sized bit-field falls into this category.  This was not handled
correctly for C structs and in G++-11 only handled correctly because
such fields were eliminated early by the front end.

gcc/ChangeLog:

PR target/102024
* config/arm/arm.cc (aapcs_vfp_sub_candidate): Handle zero-sized
bit-fields.  Detect cases where a warning may be needed.
(aapcs_vfp_is_call_or_return_candidate): Emit a note if
a zero-sized bit-field has caused parameter passing to change.

gcc/testsuite/ChangeLog:

PR target/102024
* gcc.target/arm/aapcs/vfp26.c: New test.

arm: temporarily disable 'local' pcs selection (PR96882)

The arm port has an optimization used during selection of the
function's ABI to permit deviation from the strict ABI when the
function does not escape the current translation unit.

Unfortunately, the ABI selection it makes can be unsafe if it changes
how a result is returned because not enough information is available
via the RETURN_IN_MEMORY hook to determine where the function gets
used.  This can result in some parts of the compiler thinking a value
is returned in memory while others think it is returned in registers.

To mitigate this, this patch temporarily disables the optimization and
falls back to using the default ABI for the translation.

gcc/ChangeLog:

PR target/96882
* config/arm/arm.cc (arm_get_pcs_model): Disable selection of
ARM_PCS_AAPCS_LOCAL.

[nvptx] Add __PTX_ISA_VERSION_{MAJOR,MINOR}__

Add preprocessor macros __PTX_ISA_VERSION_MAJOR__ and
__PTX_ISA_VERSION_MINOR__.

For the default 6.0, we have:
...
 $ echo | cc1 -E -dD - 2>&1 | grep PTX_ISA_VERSION
 #define __PTX_ISA_VERSION_MAJOR__ 6
 #define __PTX_ISA_VERSION_MINOR__ 0
...
and for 3.1, we have:
...
 $ echo | cc1 -mptx=3.1 -E -dD - 2>&1 | grep PTX_ISA_VERSION
 #define __PTX_ISA_VERSION_MAJOR__ 3
 #define __PTX_ISA_VERSION_MINOR__ 1
...

These can be used to express things like:
...
 #if __PTX_ISA_VERSION_MAJOR__ >= 4 && __PTX_ISA_VERSION_MAJOR__ >= 1
   /* Code using %dynamic_smem_size.  */
 #else
   /* Fallback code.  */
 #endif
...

Tested on nvptx.

gcc/ChangeLog:

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

PR target/104857
* config/nvptx/nvptx-c.cc (nvptx_cpu_cpp_builtins): Emit
__PTX_ISA_VERSION_MAJOR__ and __PTX_ISA_VERSION_MINOR__.
* config/nvptx/nvptx.cc (ptx_version_to_number): New function.
* config/nvptx/nvptx-protos.h (ptx_version_to_number): Declare.

gcc/testsuite/ChangeLog:

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

PR target/104857
* gcc.target/nvptx/ptx31.c: New test.
* gcc.target/nvptx/ptx60.c: New test.
* gcc.target/nvptx/ptx63.c: New test.
* gcc.target/nvptx/ptx70.c: New test.

[nvptx] Update help text for m64

In the docs we have for m64:
...
Ignored, but preserved for backward compatibility.  Only 64-bit ABI is
supported.
...

But with --target-help, we have instead:
...
$ gcc --target-help
  ...
  -m64    Generate code for a 64-bit ABI.
...
which could be interpreted as meaning that generating code for a 32-bit ABI is
still possible.

Fix this by instead emitting the same text as in the docs:
...
  -m64    Ignored, but preserved for backward compatibility.  Only 64-bit
          ABI is supported.
...

Tested on nvptx.

gcc/ChangeLog:

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

* config/nvptx/nvptx.opt (m64): Update help text to reflect that it
is ignored.

[nvptx] Add march-map

Say we have an sm_50 board, and we want to run a benchmark using the highest
possible march setting.

Currently there's march=sm_30, march=sm_35, march=sm_53, but no march=sm_50.

So, we'd need to pick march=sm_35.

Likewise, for a test script that handles multiple boards, we'd need a mapping
from native board sm_xx to march, which might have to be updated with newer
gcc releases.

Add an option march-map, such that we can just specify march-map=sm_50, and
let the compiler map this to the appropriate march.

The option is implemented as a list of aliases, such that we have a somewhat
lengthy (17 lines in total):
...
$ gcc --help=target
  ...
  -march-map=sm_30            Same as -misa=sm_30.
  -march-map=sm_32            Same as -misa=sm_30.
  ...
  -march-map=sm_87            Same as -misa=sm_80.
  -march-map=sm_90            Same as -misa=sm_80.
...

This implementation was chosen in the hope that it'll be easier if
we end up with some misa multilib.

It would be nice to have the mapping list generated from an updated
nvptx-sm.def, but for now it's spelled out in nvptx.opt.

Tested on nvptx.

gcc/ChangeLog:

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

PR target/104714
* config/nvptx/nvptx.opt (march-map=*): Add aliases.

gcc/testsuite/ChangeLog:

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

PR target/104714
* gcc.target/nvptx/march-map.c: New test.

Disable gathers for znver3 for vectors with 2 or 4 elements

gcc/ChangeLog:

2022-03-28  Jan Hubicka  <hubicka@ucw.cz>

* config/i386/i386-builtins.cc (ix86_vectorize_builtin_gather): Test
TARGET_USE_GATHER_2PARTS and TARGET_USE_GATHER_4PARTS.
* config/i386/i386.h (TARGET_USE_GATHER_2PARTS): New macro.
(TARGET_USE_GATHER_4PARTS): New macro.
* config/i386/x86-tune.def (X86_TUNE_USE_GATHER_2PARTS): New tune
(X86_TUNE_USE_GATHER_4PARTS): New tune

[nvptx] Add march alias for misa

The target option misa has the following description:
...
$ gcc --target-help 2>&1 | grep misa
  -misa=                      Specify the PTX ISA target architecture to use.
...

The name misa is somewhat poorly chosen.  It suggests that for a use
-misa=sm_30, sm_30 is the name of a specific Instruction Set Architecture.
Instead, sm_30 is the name of a specific target architecture in the generic
PTX Instruction Set Architecture.

Futhermore, there's mptx, which also has ISA in the description:
...
  -mptx=                      Specify the PTX ISA version to use.
...

Add the more intuitive alias march for misa:
...
$ gcc --target-help 2>&1 | grep march
  -march=                     Alias:  Same as -misa=.
...

Tested on nvptx.

gcc/ChangeLog:

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

* config/nvptx/nvptx.opt (march): Add alias of misa.

gcc/testsuite/ChangeLog:

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

* gcc.target/nvptx/main.c: New test.
* gcc.target/nvptx/march.c: New test.

MAINTAINERS: Add myself and Lulu as LoongArch port maintainer.

2022-03-29  Chenghua Xu  <xuchenghua@loongson.cn>

ChangeLog:

* MAINTAINERS: (CPU Port Maintainers): Add myself and
Lulu as LoongArch port maintainer.

LoongArch Port: Add doc.

2022-03-29  Chenghua Xu  <xuchenghua@loongson.cn>
    Lulu Cheng  <chenglulu@loongson.cn>

gcc/ChangeLog:

* doc/install.texi: Add LoongArch options section.
* doc/invoke.texi: Add LoongArch options section.
* doc/md.texi: Add LoongArch options section.

contrib/ChangeLog:

* config-list.mk: Add LoongArch triplet.

LoongArch Port: gcc/testsuite

2022-03-29  Chenghua Xu  <xuchenghua@loongson.cn>
    Lulu Cheng  <chenglulu@loongson.cn>

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/constexpr-rom.C: Add build options for LoongArch.
* g++.old-deja/g++.abi/ptrmem.C: Add LoongArch support.
* g++.old-deja/g++.pt/ptrmem6.C: xfail for LoongArch.
* gcc.dg/20020312-2.c: Add LoongArch support.
* c-c++-common/zero-scratch-regs-10.c: Like wise
* c-c++-common/zero-scratch-regs-11.c: Like wise
* c-c++-common/zero-scratch-regs-8.c: Like wise
* c-c++-common/zero-scratch-regs-9.c: Like wise
* gcc.dg/loop-8.c: Skip on LoongArch.
* gcc.dg/torture/stackalign/builtin-apply-2.c: Likewise.
* gcc.dg/tree-ssa/ssa-fre-3.c: Likewise.
* go.test/go-test.exp: Define the LoongArch target.
* lib/target-supports.exp: Like wise.
* gcc.target/loongarch/loongarch.exp: New file.
* gcc.target/loongarch/tst-asm-const.c: Like wise.
* gcc.target/loongarch/larch-builtin.c: Like wise.

LoongArch Port: libgomp

2022-03-29  Chenghua Xu  <xuchenghua@loongson.cn>
    Lulu Cheng  <chenglulu@loongson.cn>

libgomp/ChangeLog:

* configure.tgt: Add LoongArch triplet.

LoongArch Port: Regenerate libgcc/configure.

2022-03-29  Chenghua Xu  <xuchenghua@loongson.cn>
    Lulu Cheng  <chenglulu@loongson.cn>

libgcc/ChangeLog:

* configure: Regenerate file.

LoongArch Port: libgcc

2022-03-29  Chenghua Xu  <xuchenghua@loongson.cn>
    Lulu Cheng  <chenglulu@loongson.cn>

libgcc/ChangeLog:

* config/loongarch/crtfastmath.c: New file.
* config/loongarch/linux-unwind.h: Like wise.
* config/loongarch/sfp-machine.h: Like wise.
* config/loongarch/t-crtstuff: Like wise.
* config/loongarch/t-loongarch: Like wise.
* config/loongarch/t-loongarch64: Like wise.
* config/loongarch/t-softfp-tf: Like wise.
* config.host: Add LoongArch tuples.
* configure.ac: Add LoongArch support.

LoongArch Port: Builtin macros.

2022-03-29  Chenghua Xu  <xuchenghua@loongson.cn>
    Lulu Cheng  <chenglulu@loongson.cn>

gcc/ChangeLog:

* config/loongarch/loongarch-c.cc

LoongArch Port: Builtin functions.

2022-03-29  Chenghua Xu  <xuchenghua@loongson.cn>
    Lulu Cheng  <chenglulu@loongson.cn>

gcc/ChangeLog:

* config/loongarch/larchintrin.h: New file.
* config/loongarch/loongarch-builtins.cc: New file.

LoongArch Port: Machine description C files and .h files.

2022-03-29  Chenghua Xu  <xuchenghua@loongson.cn>
    Lulu Cheng  <chenglulu@loongson.cn>

gcc/ChangeLog:

* config/host-linux.cc: Add LoongArch support.
* config/loongarch/loongarch-protos.h: New file.
* config/loongarch/loongarch-tune.h: Likewise.
* config/loongarch/loongarch.cc: Likewise.
* config/loongarch/loongarch.h: Likewise.

LoongArch Port: Machine description files.

2022-03-29  Chenghua Xu  <xuchenghua@loongson.cn>
    Lulu Cheng  <chenglulu@loongson.cn>

gcc/ChangeLog:

* config/loongarch/constraints.md: New file.
* config/loongarch/generic.md: New file.
* config/loongarch/la464.md: New file.
* config/loongarch/loongarch-ftypes.def: New file.
* config/loongarch/loongarch-modes.def: New file.
* config/loongarch/loongarch.md: New file.
* config/loongarch/predicates.md: New file.
* config/loongarch/sync.md: New file.

LoongArch Port: Regenerate gcc/configure.

2022-03-29  Chenghua Xu  <xuchenghua@loongson.cn>
    Lulu Cheng  <chenglulu@loongson.cn>

gcc/ChangeLog:

* configure: Regenerate file.

LoongArch Port: gcc build

2022-03-29  Chenghua Xu  <xuchenghua@loongson.cn>
    Lulu Cheng  <chenglulu@loongson.cn>

gcc/ChangeLog:

* common/config/loongarch/loongarch-common.cc: New file.
* config/loongarch/genopts/genstr.sh: New file.
* config/loongarch/genopts/loongarch-strings: New file.
* config/loongarch/genopts/loongarch.opt.in: New file.
* config/loongarch/loongarch-str.h: New file.
* config/loongarch/gnu-user.h: New file.
* config/loongarch/linux.h: New file.
* config/loongarch/loongarch-cpu.cc: New file.
* config/loongarch/loongarch-cpu.h: New file.
* config/loongarch/loongarch-def.c: New file.
* config/loongarch/loongarch-def.h: New file.
* config/loongarch/loongarch-driver.cc: New file.
* config/loongarch/loongarch-driver.h: New file.
* config/loongarch/loongarch-opts.cc: New file.
* config/loongarch/loongarch-opts.h: New file.
* config/loongarch/loongarch.opt: New file.
* config/loongarch/t-linux: New file.
* config/loongarch/t-loongarch: New file.
* config.gcc: Add LoongArch support.
* configure.ac: Add LoongArch support.

contrib/ChangeLog:

* gcc_update (files_and_dependencies): Add
  config/loongarch/loongarch.opt and config/loongarch/loongarch-str.h.

LoongArch Port: Regenerate configure

2022-03-29  Chenghua Xu  <xuchenghua@loongson.cn>
    Lulu Cheng  <chenglulu@loongson.cn>

ChangeLog:

* configure.ac: Add LoongArch tuples.
* configure: Regenerate.

config/ChangeLog:

* picflag.m4: Default add build option '-fpic' for LoongArch.

options: Fix 'enabledby_negargs' typo in 'LangEnabledBy' option property diagnostics

Originally introduced almost ten years ago in
r193303/commit 0829c7f7c5210cd1581042115cfe95c97283f44c
"optc-gen.awk: Factor code out to...".

gcc/
* opt-functions.awk (lang_enabled_by): Fix 'enabledby_negargs'
typo.

libstdc++: Workaround for missing 'using enum' in Clang 12

Once we no longer care about older compilers without this feature, we
can drop these static data members, so the names don't have to be
visible at class scope.

libstdc++-v3/ChangeLog:

* libsupc++/compare (_Strong_order) [!__cpp_using_enum]: Add
static data members for _Fp_fmt enumerators.

libstdc++: Fix incorrect preprocessor conditions in <version>

The conditions that guard the feature test macros in <version> should
match the main definitions of the macros in other headers.

This doesn't matter for GCC, because it supports all the conditions
being tested here, but it does matter for non-GCC compilers without the
relevant C++20 features.

libstdc++-v3/ChangeLog:

* include/std/version (__cpp_lib_variant): Fix conditions to
match <variant>.
(__cpp_lib_expected): Fix condition to match <expected>.

testsuite: Check fpic support in pr103275.c

Test must check for effective support of fpic.

gcc/testsuite/ChangeLog:
* gcc.target/i386/pr103275.c: Add missing
dg-require-effective-target for checking fpic.

testsuite: fixup pr97521.c and pr96713.c on i686-*

On targets that do not have MXX/SSE enabled by default, pr97521
and pr96713 fail because they emit warnings:

pr97521.c:12:1: warning: MMX vector return without MMX enabled
                changes the ABI [-Wpsabi]
pr97521.c:11:1: note: the ABI for passing parameters with
                16-byte alignment has changed in GCC 4.6
pr97521.c:11:1: warning: SSE vector argument without SSE enabled
                changes the ABI [-Wpsabi]

Add -Wno-psabi to dg-options.

gcc/testsuite/ChangeLog:
* gcc.target/i386/pr97521.c: Add -Wno-psabi to dg-options.
* gcc.dg/analyzer/pr96713.c: Likewise.

tree-optimization/105080 - make sure SCEV is available for ranger

When doing format diagnostics at -O0 we should make sure to make
SCEV available to avoid false positives due to ranges we otherwise
can trivially compute.

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

PR tree-optimization/105080
* tree-ssa-strlen.cc (printf_strlen_execute): Always init
loops and SCEV.

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

analyzer: ensure that we purge state when reusing a conjured_svalue [PR105087]

PR analyzer/105087 describes a false positive from
-Wanalyzer-double-free in which the analyzer erroneously considers two
successive inlined vasprintf calls to have allocated the same pointer.

The root cause is that the result written back from vasprintf is a
conjured_svalue, and that we normally purge state when reusing a
conjured_svalue, but various places in the code were calling
region_model_manager::get_or_create_conjured_svalue but failing to
then call region_model::purge_state_involving on the result.

This patch fixes things by moving responsibility for calling
region_model::purge_state_involving into
region_model_manager::get_or_create_conjured_svalue, so that it is
always called when reusing a conjured_svalue, fixing the false positive.

gcc/analyzer/ChangeLog:
PR analyzer/105087
* analyzer.h (class conjured_purge): New forward decl.
* region-model-asm.cc (region_model::on_asm_stmt): Add
conjured_purge param to calls binding_cluster::on_asm and
region_model_manager::get_or_create_conjured_svalue.
* region-model-impl-calls.cc
(call_details::get_or_create_conjured_svalue): Likewise for call
to region_model_manager::get_or_create_conjured_svalue.
(region_model::impl_call_fgets): Remove call to
region_model::purge_state_involving, as this is now done
implicitly by call_details::get_or_create_conjured_svalue.
(region_model::impl_call_fread): Likewise.
(region_model::impl_call_strchr): Pass conjured_purge param to
call to region_model_manager::get_or_create_conjured_svalue.
* region-model-manager.cc (conjured_purge::purge): New.
(region_model_manager::get_or_create_conjured_svalue): Add
param "p".  Use it to purge state when reusing an existing
conjured_svalue.
* region-model.cc (region_model::on_call_pre): Replace call to
region_model::purge_state_involving with passing conjured_purge
to region_model_manager::get_or_create_conjured_svalue.
(region_model::handle_unrecognized_call): Pass conjured_purge to
store::on_unknown_fncall.
* region-model.h
(region_model_manager::get_or_create_conjured_svalue): Add param
"p".
* store.cc (binding_cluster::on_unknown_fncall): Likewise.  Pass
it on to region_model_manager::get_or_create_conjured_svalue.
(binding_cluster::on_asm): Likewise.
(store::on_unknown_fncall): Add param "p" and pass it on to
binding_cluster::on_unknown_fncall.
* store.h (binding_cluster::on_unknown_fncall): Add param p.
(binding_cluster::on_asm): Likewise.
(store::on_unknown_fncall): Likewise.
* svalue.h (class conjured_purge): New.

gcc/testsuite/ChangeLog:
* gcc.dg/analyzer/pr105087-1.c: New test.
* gcc.dg/analyzer/pr105087-2.c: New test.
* gcc.dg/analyzer/vasprintf-1.c: New test.

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

analyzer: fix ICE with incorrect lookup of cgraph node [PR105074]

gcc/analyzer/ChangeLog:
PR analyzer/105074
* region.cc (ipa_ref_requires_tracking): Drop "context_fndecl",
instead using the ref->referring to get the cgraph node of the
caller.
(symnode_requires_tracking_p): Likewise.

gcc/testsuite/ChangeLog:
PR analyzer/105074
* gcc.dg/analyzer/pr105074.c: New test.
* gcc.dg/analyzer/untracked-1.c (extern_fn_char_ptr): New decl.
(test_13): New.

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

Daily bump.

ctfout: use ctfc_get_num_ctf_vars instead

A minor cosmetic fix.

2022-03-28  Indu Bhagat  <indu.bhagat@oracle.com>

gcc/ChangeLog:

* ctfout.cc (ctf_preprocess): Use ctfc_get_num_ctf_vars instead.
(output_ctf_vars): Likewise.