c++: alignment of local typedef in template [PR65211]

Because common_handle_aligned_attribute only applies the alignment to the
TREE_TYPE of a typedef, not the DECL_ORIGINAL_TYPE, we need to copy it
explicitly in tsubst.

PR c++/65211

gcc/cp/ChangeLog:

* pt.cc (tsubst_decl) [TYPE_DECL]: Copy TYPE_ALIGN.

gcc/testsuite/ChangeLog:

* g++.target/i386/vec-tmpl1.C: New test.

c++: local fn and generic lambda [PR97219]

When instantiating the op() for a generic lambda, we can no longer do name
lookup inside function scopes enclosing the lambda, so we need to remember
the lookup result from processing the definition of the lambda.  So the code
in finish_call_expr to throw away the lookup result and instead look it up
again at instantiation time needs to be adjusted.  The approach I take is to
only discard the result if the local extern comes from dependent scope; once
the enclosing function template is instantiated and we're regenerating the
lambda, then we can remember the result of lookup.  We also need any default
arguments to be instantiated at that point.

PR c++/97219

gcc/cp/ChangeLog:

* name-lookup.cc (dependent_local_decl_p): New.
* cp-tree.h (dependent_local_decl_p): Declare.
* semantics.cc (finish_call_expr): Use it.
* pt.cc (tsubst_arg_types): Also substitute default args
for local externs.

gcc/testsuite/ChangeLog:

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

c++: template conversion op [PR101698]

Asking for conversion to a dependent type also makes a BASELINK dependent.

PR c++/101698

gcc/cp/ChangeLog:

* pt.cc (tsubst_baselink): Also check dependent optype.

gcc/testsuite/ChangeLog:

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

c++: NRV and ref-extended temps [PR101442]

This issue goes back to r83221, where the cleanup for extended ref temps
changed from being unconditional to being tied to the declaration they
formed part of the initializer for.

The named return value optimization changes the cleanup for the NRV variable
to only run on the EH path; we don't want that change to affect temporary
cleanups.  The perform_member_init change isn't necessary (there 'decl' is a
COMPONENT_REF), it's just for consistency.

PR c++/101442

gcc/cp/ChangeLog:

* decl.cc (cp_finish_decl): Don't pass decl to push_cleanup.
* init.cc (perform_member_init): Likewise.
* semantics.cc (push_cleanup): Adjust comment.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/initlist-nrv1.C: New test.

c++: add test [PR105265]

This was fixed by r12-1165, but good to have a test that doesn't need
-fno-elide-constructors.

PR c++/105265
PR c++/100838

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/initlist-new6.C: New test.

Daily bump.

go.test: update issue10441.go to current upstream version

This test only needs to be compiled, not linked.

aarch64: Make sure the UF divides the VF [PR105254]

In this PR, we were trying to set the unroll factor to a value higher
than the minimum VF (or more specifically, to a value that doesn't
divide the VF).  I guess there are two approaches to this: let the
target pick any value it likes and make target-independent code pare
it back to something that makes sense, or require targets to supply
sensible values from the outset.  This patch goes for the latter
approach.

gcc/
PR tree-optimization/105254
* config/aarch64/aarch64.cc
(aarch64_vector_costs::determine_suggested_unroll_factor): Take a
loop_vec_info as argument.  Restrict the unroll factor to values
that divide the VF.
(aarch64_vector_costs::finish_cost): Update call accordingly.

gcc/testsuite/
PR tree-optimization/105254
* g++.dg/vect/pr105254.cc: New test.

OpenMP/Fortran: Fix EXIT in loop diagnostic [PR105242]

gcc/fortran/ChangeLog:

PR fortran/105242
* match.cc (match_exit_cycle): Handle missing OMP LOOP, DO and SIMD
directives in the EXIT/CYCLE diagnostic.

gcc/testsuite/ChangeLog:

PR fortran/105242
* gfortran.dg/gomp/loop-exit.f90: New test.

c++: empty base constexpr -fno-elide-ctors [PR105245]

The patch for 100111 extended our handling of empty base elision to the case
where the derived class has no other fields, but we still need to make sure
that there's some initializer for the derived object.

PR c++/105245
PR c++/100111

gcc/cp/ChangeLog:

* constexpr.cc (cxx_eval_store_expression): Build a CONSTRUCTOR
as needed in empty base handling.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1y/constexpr-empty2.C: Add -fno-elide-constructors.

d: Merge upstream dmd 4d1bfcf14, druntime 9ba9a6ae, phobos c0cc5e917.

D front-end changes:

    - Import dmd v2.099.1.
    - Added `@mustuse' attribute, implmenting DIP 1038.
    - Added `.tupleof` property for static arrays

D runtime changes:

    - Import druntime v2.099.1.

Phobos changes:

    - Import phobos v2.099.1.
    - Zlib bindings have been updated to 1.2.12.

gcc/d/ChangeLog:

* Make-lang.in (D_FRONTEND_OBJS): Add d/common-bitfields.o,
d/mustuse.o.
* d-ctfloat.cc (CTFloat::isIdentical): Don't treat NaN values as
identical.
* dmd/MERGE: Merge upstream dmd 4d1bfcf14.
* expr.cc (ExprVisitor::visit (VoidInitExp *)): New.

libphobos/ChangeLog:

* libdruntime/MERGE: Merge upstream druntime 9ba9a6ae.
* src/MERGE: Merge upstream phobos c0cc5e917.

tree-optimization/105263 - reassoc and DFP

reassoc has certain tricks which in the end depend on the ability
to undo them.  For DFP creating a -1. constant is easy but
re-identifying is appearantly not - real_minus_onep rejects those
outright for DFP.  So we have to disable (at least) this one trick.

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

PR tree-optimization/105263
* tree-ssa-reassoc.cc (try_special_add_to_ops): Do not consume
negates in multiplication chains with DFP.

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

tree.cc: Use useless_type_conversion_p in tree_builtin_call_types_compatible_p while in gimple form [PR105253]

tree_builtin_call_types_compatible_p uses TYPE_MAIN_VARIANT comparisons
or tree_nop_conversion_p to ensure a builtin has correct GENERIC arguments.
Unfortunately this regressed when get_call_combined_fn is called during
GIMPLE optimizations.  E.g. when number_of_iterations_popcount is called,
it doesn't ensure TYPE_MAIN_VARIABLE compatible argument type, it picks
__builtin_popcount{,l,ll} based just on types' precision and doesn't
fold_convert the arg to the right type.  We are in GIMPLE, such conversions
are useless...
So, either we'd need to fix number_of_iterations_popcount to add casts
and inspect anything else that creates CALL_EXPRs late, or we can
in tree_builtin_call_types_compatible_p just use the GIMPLE type
comparisons (useless_type_conversion_p) when we are in GIMPLE form and
the TYPE_MAIN_VARIANT comparison or tree_nop_conversion_p test otherwise.

I think especially this late in stage4 the latter seems safer to me.

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

PR middle-end/105253
* tree.cc (tree_builtin_call_types_compatible_p): If PROP_gimple,
use useless_type_conversion_p checks instead of TYPE_MAIN_VARIANT
comparisons or tree_nop_conversion_p checks.

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

c++: Treat alignas align_expr and aligned attribute's operand as manifestly constant evaluation [PR105233]

The following testcase fails, because we only constant evaluate the
alignas argument as non-manifestly constant-evaluated and as
__builtin_is_constant_evaluated appears, we make it non-constant
(the reason is that we often try to evaluate some expression without
manifestly_const_eval perhaps even multiple times before actually
evaluating it with manifestly_const_eval (e.g. when folding for warnings
and in many other places), and we don't want __builtin_is_constant_evaluated
to evaluate to false in those cases, because we could get a different
result from when we actually evaluate it with manifestly_const_eval
set).
Now, for alignas the standard seems to be clear, it says the
argument is constant-expression, which means we should
manifestly-constant-eval it.
Attributes are a fuzzy area, they are extensions and various attributes
take e.g. identifiers, or string literals etc. as arguments.

Either we can just treat alignas as manifestly-const-eval, for that
we'd need some way how to differentiate between alignas and gnu::aligned
or aligned attribute.

Another possibility is what the patch below implements, treat
both alignas and gnu::aligned and aligned attribute's argument as
manifestly-const-eval and not do that for other attributes.

Another is to go through all attributes and figure out for which
such treatment is useful (e.g. those that expect INTEGER_CST as argument),
and either add a new column in the attribute table or have another table
in the C++ FE to find out which attribute needs that.

Another is do that for all the attribute arguments that are EXPR_P
and see what breaks (bet that it could be quite risky this late in
GCC 12 cycle and especially for backporting).

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

PR c++/105233
* decl2.cc (cp_check_const_attributes): For aligned attribute
pass manifestly_const_eval=true to fold_non_dependent_expr.

* g++.dg/cpp2a/is-constant-evaluated13.C: New test.

testsuite: Increase auto-inlining param in gcc.dg/ipa/remref-7.c (PR 105183)

A scan dump of testsuite gcc.dg/ipa/remref-7.c fails on a number of
platforms.  I investigated only i?86-*-* with -mno-sse but assume the
issue is the same on all of the affected platform.

Because function bar is not inlined there even though it is only
called once, the process that is being tested is simply not triggered.
This can be "fixed" by increasing parameter max-inline-insns-auto to
something high, I randomly picked 100.

I have only manually tested the change but hopefully that is enough.

gcc/testsuite/ChangeLog:

2022-04-08  Martin Jambor  <mjambor@suse.cz>

PR testsuite/105183
* gcc.dg/ipa/remref-7.c: Add --param max-inline-insns-auto=100 to options.

c++: ambiguous call not diagnosed after DR2352 [PR97296]

DR 2352 changed the definitions of reference-related (so that it uses
"similar type" instead of "same type") and of reference-compatible (use
a standard conversion sequence).  That means that reference-related is
now more broad, which means that we will be binding more things directly.

The original patch for DR 2352 caused some problems, which were fixed in
r276251 by creating a "fake" ck_qual in direct_reference_binding, so
that in

  void f(int *); // #1
  void f(const int * const &); // #2
  int *x;
  int main()
  {
    f(x); // call #1
  }

we call #1.  The extra ck_qual in #2 causes compare_ics to select #1,
which is a better match for "int *" because then we don't have to do
a qualification conversion.

Let's turn to the problem in this PR.  We have

  void f(const int * const &); // #1
  void f(const int *); // #2
  int *x;
  int main()
  {
    f(x);
  }

We arrive in compare_ics to decide which one is better. The ICS for #1
looks like

    ck_ref_bind      <-    ck_qual         <-   ck_identity
  const int *const &     const int *const         int *

and the ICS for #2 is

    ck_qual     <-  ck_rvalue   <-  ck_identity
  const int *          int *           int *

We strip the reference and then comp_cv_qual_signature when comparing two
ck_quals sees that "const int *" is a proper subset of "const int *const"
and we return -1.  But that's wrong; presumably the top-level "const"
should be ignored and the call should be ambiguous.  This patch adjust
the type of the "fake" ck_qual so that this problem doesn't arise.

PR c++/97296

gcc/cp/ChangeLog:

* call.cc (direct_reference_binding): strip_top_quals when creating
a ck_qual.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/ref-bind4.C: Add dg-error.
* g++.dg/cpp0x/ref-bind8.C: New test.

middle-end/105259 - adjust gcc.target/i386/auto-init-4.c

This adjusts the FAILing testcase to only check for the pieces
that work.  The bug tracks improving pattern-init for long double.

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

PR middle-end/105259
* gcc.target/i386/auto-init-4.c: Adjust.

i386: Fix infinite loop under -mrelax-cmpxchg-loop [PR 103069]

For -mrelax-cmpxchg-loop which relaxes atomic_fetch_<logic> loops,
there is a missing set to %eax when compare fails, which would result
in infinite loop in some benchmark. Add set to %eax to avoid it.

gcc/ChangeLog:

PR target/103069
* config/i386/i386-expand.cc (ix86_expand_cmpxchg_loop):
  Add missing set to target_val at pause label.

attribs: Restrict decl_attributes DECL_FUNCTION_SPECIFIC_TARGET changes to targets that care about target attributes/pragmas [PR105234]

The following code is rejected e.g. on mips64el-linux (but I think many
other targets which don't support target attribute or pragma).
The problem is that the change to decl_attributes below is done
unconditionally and with just #pragma GCC push_options/pop_options pair
we have target_option_default_node NULL, but after popping options
target_option_current_node becomes non-NULL and this decl_attribute
spot fills in DECL_FUNCTION_SPECIFIC_TARGET of a subset of a functions.
Those appearing before push_options/pop_options will have it NULL and
as target_option_default_node is also NULL on those targets, the default
can_inline_p will refuse to inline any functions defined with NULL
DECL_FUNCTION_SPECIFIC_TARGET into any function with non-NULL
DECL_FUNCTION_SPECIFIC_TARGET (even when nothing in the options really
changed).

The following patch restricts that snippet to targets that care (initialize
target_option_default_node to non-NULL to the command line options early)
which include all targets that actually implement target attribute and/or
pragma.

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

PR target/105234
* attribs.cc (decl_attributes): Don't set
DECL_FUNCTION_SPECIFIC_TARGET if target_option_default_node is
NULL.

* gcc.c-torture/compile/pr105234.c: New test.

tree-optimization/105250 - adjust fold_convertible_p PR105140 fix

The following reverts the original PR105140 fix and goes for instead
applying the additional fold_convert constraint for VECTOR_TYPE
conversions also to fold_convertible_p.  I did not try sanitizing
all of this at this point.

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

PR tree-optimization/105250
* fold-const.cc (fold_convertible_p): Revert
r12-7979-geaaf77dd85c333, instead check for size equality
of the vector types involved.

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

Revert "tree-optimization/104912 - ensure cost model is checked first"

This reverts commit ac8340ee4d1e65f3fd41c547b16895875f4aefa7.

tree-optimization/104912 - ensure cost model is checked first

The following makes sure that when we build the versioning condition
for vectorization including the cost model check, we check for the
cost model and branch over other versioning checks.  That is what
the cost modeling assumes, since the cost model check is the only
one accounted for in the scalar outside cost.  Currently we emit
all checks as straight-line code combined with bitwise ops which
can result in surprising ordering of checks in the final assembly.

Since loop_version accepts only a single versioning condition
the splitting is done after the fact.

The result is a 1.5% speedup of 416.gamess on x86_64 when compiling
with -Ofast and tuning for generic or skylake.  That's not enough
to recover from the slowdown when vectorizing but it now cuts off
the expensive alias versioning test.

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

PR tree-optimization/104912
* tree-vect-loop-manip.cc (vect_loop_versioning): Split
the cost model check to a separate BB to make sure it is
checked first and not combined with other version checks.

scev: Fix a comment typo

When looking at the kernel __popcountdi2 issue, I've noticed a comment typo.

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

* tree-scalar-evolution.cc (expression_expensive_p): Fix a comment typo.

libgomp: Fix a documentation typo

This fixes a typo in the 5.0 feature support table.

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

* libgomp.texi: Fix a typo - mutexinouset -> mutexinoutset.

ppc: testsuite: skip pr60203 on no ldbl128

If neither 128-bit long double format is available, skip pr60203.c.

for  gcc/testsuite/ChangeLog

* gcc.target/powerpc/pr60203.c: Skip on no 128-bit long double.

ppc: testsuite: PROMOTE_MODE fallout pr56605 [PR102146]

The test expects a compare of DImode values, but after the removal of
PROMOTE_MODE from rs6000/, we get SImode.  Adjust the expectations.

for  gcc/testsuite/ChangeLog

PR target/102146
* gcc.target/powerpc/pr56605.c: Accept SImode compare operand.

mips: testsuite: enforce -ffat-lto-objects for pr102024-4.c

The body of func is optimized away with -flto -fno-fat-lto-objects, so
the psABI inform is not emitted, causing a test failure.

gcc/testsuite/

* gcc.target/mips/pr102024-4.c (dg-options): Add
-ffat-lto-objects.

Daily bump.

libstdc++: Prefer to use mmap instead of malloc in libbacktrace

As reported in PR libbacktrace/105240, libbacktrace leaks memory when
using malloc for allocations. I originally thought it would be simpler
to just use malloc unconditionally (because it's supported on all
targets) but the leaks make that problematic.

This adds libbacktrace's detection for mmap to the libstdc++
configury, so that we use mmap.c and mmapio.c when possible. This avoids
the leaks seen previously, at least on linux.

libstdc++-v3/ChangeLog:

* acinclude.m4 (GLIBCXX_ENABLE_BACKTRACE): Check for mmap.
* config.h.in: Regenerate.
* configure: Regenerate.

libstdc++: shrink-to-fit in std::basic_stacktrace::current(skip, max)

If a large stacktrace is reduced to a max depth that is less than half
the capacity it will now be reallocated to remove the unused capacity.

libstdc++-v3/ChangeLog:

* include/std/stacktrace (basic_stacktrace::current): Reallocate
a smaller container if the unused capacity is larger than the
used size.

libstdc++: Use allocator to construct std::stacktrace_entry objects

Because std::basic_stacktrace<A> is an allocator-aware container its
elements should be initialized using allocator_traits<A>::construct and
destroyed using allocator_traits<A>::destroy.

This adds new _M_clone and _M_assign helper functions to construct
elements correctly and uses those functions instead of calling
std::uninitialized_copy_n.

The _Impl::_M_destroy function needs to be passed an allocator to
destroy the elements correctly, so is replaced by _M_resize which can
also be used to trim the container to a smaller size.

Because destroying and creating std::stacktrace_entry objects is cheap,
the copy/move assignment operators can just destroy all existing
elements and use _Impl._M_clone or _Impl._M_assign to create new ones.

libstdc++-v3/ChangeLog:

* include/std/stacktrace (basic_stacktrace): Use _Impl::_M_clone
or _Impl::_M_assign to initialize elements in allocated storage.
(basic_stacktrace::_M_clear()): Use _Impl::_M_resize instead of
_Impl::_M_destroy.
(basic_stacktrace::_Impl::_M_destroy()): Replace with ...
(basic_stacktrace::_Impl::_M_resize(size_type, allocator&)): New
function.
(basic_stacktrace::_Impl::_M_push_back): Use _M_xclone. Construct
new element using allocator.
(basic_stacktrace::_Impl::_M_clone): New function.
(basic_stacktrace::_Impl::_M_xclone): New function.
(basic_stacktrace::_Impl::_M_assign): New function.

libstdc++: Use nothrow new in std::stacktrace

We can avoid the overhead of handling a bad_alloc exception from
std::allocator<std::stacktrace_entry>::allocate by just calling the
nothrow operator new instead.

libstdc++-v3/ChangeLog:

* include/std/stacktrace (basic_stacktrace::_Impl::_M_allocate):
Use nothrow new instead of try block for std::allocator.
(basic_stacktrace::_Impl::_M_deallocate): Use delete for
std::allocator.

libstdc++: Reduce memory usage in std::stacktrace::current

This adds an alternative callback for use in the overload of
basic_stacktrace::current that takes a max_depth parameter. The new
callback will not allow the container to grow past the initial capacity,
which is set to the specified maximum depth.  This avoids allocating
memory for hundreds of frames only to discard them again because of a
small maximum depth limit.

For larger maximum depths the normal callback is used, with a smaller
initial capacity that can grow as needed. The container will be resized
to the given max depth after the entire backtrace has been produced
(relying on the fact that std::stacktrace_entry objects are trivially
destructible to elide their destruction).

Currently the value for "larger" limits is 128, so a max depth <= 128
will allocate capacity for exactly that many frames. A larger max depth
(or an unspecified max depth) will use an initial capacity of 64 frames
and grow as needed. Since each frame is only a uintptr_t value it might
be reasonable to increase the first value so that memory usage can be
capped for larger maximum depths.

This change also delays the creation of the libbacktrace state until we
actually need it, so that the state is not created if allocation fails.

libstdc++-v3/ChangeLog:

* include/std/stacktrace (basic_stacktrace::current): Replace
calls to _M_reserve and _S_curr_cb with call to _M_prepare.
Check return value of backtrace_simple when max depth given.
(basic_stacktrace::_M_reserve): Remove.
(basic_stacktrace::_S_curr_cb): Remove.
(basic_stacktrace::_M_prepare(size_type)): New function to
reserve initial capacity and return callback.
(basic_stacktrace::_Impl::_M_allocate): Remove check for 0 < n
and remove redundant zeroing of _M_frames and _M_capacity.
(basic_stacktrace::_Impl::_M_push_back): Add [[unlikely]]
attribute. Assign _Impl instead of swapping.
* testsuite/19_diagnostics/stacktrace/current.cc: New test.

libgccjit: Add support for setting the alignment [PR104293]

gcc/jit/
PR jit/104293
* docs/_build/texinfo/libgccjit.texi: Regenerate.
* docs/topics/compatibility.rst (LIBGCCJIT_ABI_24): New ABI tag.
* docs/topics/expressions.rst: Add documentation for the
functions gcc_jit_lvalue_set_alignment and
gcc_jit_lvalue_get_alignment.
* jit-playback.h: New function (set_alignment).
* jit-recording.cc: New function (set_alignment).
* jit-recording.h: New functions (set_alignment, get_alignment)
and new field (m_alignment).
* libgccjit.cc: New functions (gcc_jit_lvalue_get_alignment,
gcc_jit_lvalue_set_alignment)
* libgccjit.h: New functions (gcc_jit_lvalue_get_alignment,
gcc_jit_lvalue_set_alignment)
* libgccjit.map (LIBGCCJIT_ABI_24): New ABI tag.

gcc/testsuite/
PR jit/104293
* jit.dg/all-non-failing-tests.h: Mention
test-setting-alignment.
* jit.dg/test-setting-alignment.c: New test.

libgccjit: Add function to hide stderr logs [PR104073]

gcc/jit/
PR jit/104073
* docs/_build/texinfo/libgccjit.texi: Regenerate.
* docs/topics/compatibility.rst (LIBGCCJIT_ABI_23): New ABI tag.
* docs/topics/contexts.rst: Add documentation for the new
function gcc_jit_context_set_bool_print_errors_to_stderr.
* jit-common.h: New enum value
(INNER_BOOL_OPTION_PRINT_ERRORS_TO_STDERR).
* jit-recording.cc: Handle the new option
INNER_BOOL_OPTION_PRINT_ERRORS_TO_STDERR.
* libgccjit.cc: New function
(gcc_jit_context_set_bool_print_errors_to_stderr).
* libgccjit.h: New function
(gcc_jit_context_set_bool_print_errors_to_stderr).
* libgccjit.map (LIBGCCJIT_ABI_23): New ABI tag.

libgccjit: Add support for register variables [PR104072]

gcc/jit/
PR jit/104072
* docs/_build/texinfo/libgccjit.texi: Regenerate.
* docs/topics/compatibility.rst (LIBGCCJIT_ABI_22): New ABI tag.
* docs/topics/expressions.rst: Add documentation for the
function gcc_jit_lvalue_set_register_name.
* jit-playback.h: New function (set_register_name).
* jit-recording.cc: New function (set_register_name) and add
support for register variables.
* jit-recording.h: New field (m_reg_name) and new function
(set_register_name).
* libgccjit.cc: New function (gcc_jit_lvalue_set_register_name).
* libgccjit.h: New function (gcc_jit_lvalue_set_register_name).
* libgccjit.map (LIBGCCJIT_ABI_22): New ABI tag.

gcc/
PR jit/104072
* reginfo.cc: New functions (clear_global_regs_cache,
reginfo_cc_finalize) to avoid an issue where compiling the same
code multiple times gives an error about assigning the same
register to 2 global variables.
* rtl.h: New function (reginfo_cc_finalize).
* toplev.cc: Call it.

gcc/testsuite/
PR jit/104072
* jit.dg/all-non-failing-tests.h: Add new
test-register-variable.
* jit.dg/harness.h: Add -fdiagnostics-color=never to context's
command-line options.
* jit.dg/test-error-register-variable-bad-name.c: New test.
* jit.dg/test-error-register-variable-size-mismatch.c: New test.
* jit.dg/test-register-variable.c: New test.

libgccjit: Add support for bitcasts [PR104071]

gcc/jit/
PR jit/104071
* docs/_build/texinfo/libgccjit.texi: Regenerate.
* docs/topics/compatibility.rst (LIBGCCJIT_ABI_21): New ABI tag.
* docs/topics/expressions.rst: Add documentation for the
function gcc_jit_context_new_bitcast.
* jit-playback.cc: New function (new_bitcast).
* jit-playback.h: New function (new_bitcast).
* jit-recording.cc: New functions (new_bitcast,
bitcast::replay_into, bitcast::visit_children,
bitcast::make_debug_string, bitcast::write_reproducer).
* jit-recording.h: New class (bitcast) and new function
(new_bitcast, bitcast::replay_into, bitcast::visit_children,
bitcast::make_debug_string, bitcast::write_reproducer,
bitcast::get_precedence).
* libgccjit.cc: New function (gcc_jit_context_new_bitcast)
* libgccjit.h: New function (gcc_jit_context_new_bitcast)
* libgccjit.map (LIBGCCJIT_ABI_21): New ABI tag.

gcc/testsuite/
PR jit/104071
* jit.dg/all-non-failing-tests.h: Add new test-bitcast.
* jit.dg/test-bitcast.c: New test.
* jit.dg/test-error-bad-bitcast.c: New test.
* jit.dg/test-error-bad-bitcast2.c: New test.

gcc/
PR jit/104071
* toplev.cc: Call the new function tree_cc_finalize in
toplev::finalize.
* tree.cc: New functions (clear_nonstandard_integer_type_cache
and tree_cc_finalize) to clear the cache of non-standard integer
types to avoid having issues with some optimizations of
bitcast where the SSA_NAME will have a size of a cached
integer type that should have been invalidated, causing a
comparison of integer constant to fail.
* tree.h: New function (tree_cc_finalize).

libgccjit: Add support for sized integer types, including 128-bit integers [PR95325]

gcc/jit/
PR target/95325
* docs/_build/texinfo/libgccjit.texi: Regenerate
* docs/topics/compatibility.rst (LIBGCCJIT_ABI_20): New ABI tag.
* docs/topics/types.rst: Add documentation for the new types
GCC_JIT_TYPE_UINT8_T, GCC_JIT_TYPE_UINT16_T,
GCC_JIT_TYPE_UINT32_T, GCC_JIT_TYPE_UINT64_T,
GCC_JIT_TYPE_UINT128_T, GCC_JIT_TYPE_INT8_T, GCC_JIT_TYPE_INT16_T,
GCC_JIT_TYPE_INT32_T, GCC_JIT_TYPE_INT64_T, GCC_JIT_TYPE_INT128_T and
new functions (gcc_jit_compatible_types, gcc_jit_type_get_size).
* jit-builtins.cc: Add support for BT_UINT128.
* jit-common.h: Update the value of NUM_GCC_JIT_TYPES.
* jit-playback.cc: Add support for the sized integer types.
* jit-recording.cc: Add support for the sized integer types.
* jit-recording.h: Add support for comparing integer types
and new function (is_signed).
* libgccjit.cc (gcc_jit_compatible_types): New.
(gcc_jit_type_get_size) New.
* libgccjit.h: New enum variants for gcc_jit_types
(GCC_JIT_TYPE_UINT8_T, GCC_JIT_TYPE_UINT16_T,
GCC_JIT_TYPE_UINT32_T, GCC_JIT_TYPE_UINT64_T,
GCC_JIT_TYPE_UINT128_T, GCC_JIT_TYPE_INT8_T,
GCC_JIT_TYPE_INT16_T, GCC_JIT_TYPE_INT32_T,
GCC_JIT_TYPE_INT64_T, GCC_JIT_TYPE_INT128_T) and new functions
(gcc_jit_compatible_types, gcc_jit_type_get_size).
* libgccjit.map (LIBGCCJIT_ABI_20): New ABI tag.

gcc/testsuite/
PR target/95325
* jit.dg/test-types.c: Add tests for sized integer types.

c++: local function versioning [PR104669]

There were two problems with this testcase: we weren't copying the target
attribute from the second declaration to the global alias for the first
one (duplicate_decls hunk), and then we were treating the third one as
matching the earlier one even though both are versioned (decls_match hunk).
The latter change required a fix to find_last_decl (used for attribute
mismatch warnings) to give up if we see a versioned function, as in that
case we can't determine whether the decls match, because we are still in the
process of setting the attributes on the new decl.

PR c++/104669

gcc/cp/ChangeLog:

* decl.cc (decls_match): Compare versions even if not recording.
(duplicate_decls): Propagate attributes to alias.
* decl2.cc (find_last_decl): Give up if versioned.

gcc/testsuite/ChangeLog:

* g++.target/i386/mv31.C: New test.

c++: non-array new alignment [PR102071]

While considering the PR102071 patch for backporting, I noticed that I was
considering the alignment of the array new cookie even when there isn't one
because we aren't allocating an array.

PR c++/102071

gcc/cp/ChangeLog:

* init.cc (build_new_1): Check array_p for alignment.

gcc/testsuite/ChangeLog:

* g++.dg/cpp1z/aligned-new9.C: Add single-object test.

Let nvptx-as figure out the target architecture [PR97348]

... now that it has been enhanced to do so.

This is a follow-up to PR97348 commit 383400a6078d75bbfa1216c9af2c37f7e88740c9
"[nvptx] Set -misa=sm_35 by default".

gcc/
PR target/97348
* config/nvptx/nvptx.h (ASM_SPEC): Don't set.
* config/nvptx/nvptx.opt (misa): Adjust comment.

Revert "[nvptx] Use --no-verify for sm_30"

This reverts commit 12fa7641ceed9c9139e2ea7b62c11f3dc5b6f6f4.

Revert "[nvptx] Fix ASM_SPEC workaround for sm_30"

This reverts commit bf4832d6fa817f66009f100a9cd68953062add7d.

c++: requires-expr in pack expansion using pack [PR103105]

Here after dependent substitution of {Ts...} into the alias 'wrap',
since we never partially instantiate a requires-expr, we end up with a
requires-expr whose REQUIRES_EXPR_EXTRA_ARGS contains an
ARGUMENT_PACK_SELECT (which just resolves to the parameter pack Ts).
Then when hashing the resulting dependent specialization of A, we crash
from iterative_hash_template_arg since it deliberately doesn't handle
ARGUMENT_PACK_SELECT.

Like in r12-7102-gdb5f1c17031ad8, it seems the right fix here is to
resolve ARGUMENT_PACK_SELECT arguments before storing them into an
extra args tree (such as REQUIRES_EXPR).

PR c++/103105

gcc/cp/ChangeLog:

* pt.cc (build_extra_args): Call preserve_args.

gcc/testsuite/ChangeLog:

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

ipa/104303 - revert overly conservative DCE change

The following reverts the DCE change back to the original behavior
which should be handled well during the propagation stage.  That
should fix the failures Thomas Schwinge is reporting.

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

PR ipa/104303
* tree-ssa-dce.cc (mark_stmt_if_obviously_necessary): Do not
include local escaped memory as obviously necessary stores.

arm: fix testsuite failure of reg_equal_test.c [PR101755]

The test failure in PR101755 is due to the gimple optimizers getting
smarter.  But really we are just testing that RTL expansion is doing
the right thing and annotating a constant accordingly.  So rework the
test to use GIMPLE input and simplify the code entirely.  Also, this
test only ever worked on architecture versions with the MOVW/MOVT
instructions, so check for this before running.

gcc/testsuite/ChangeLog:

PR target/101755
* gcc.target/arm/reg_equal_test.c: Convert to gimple test.  Restrict
to architectures with MOVW/MOVT.

tree-optimization/105235 - clean EH in execute_cse_conv_1

When a FP conversion is removed we have to eventually clean EH.

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

PR tree-optimization/105235
* tree-ssa-math-opts.cc (execute_cse_conv_1): Clean EH and
return whether the CFG changed.
(execute_cse_sincos_1): Adjust.

* g++.dg/opt/pr105235-1.C: New testcase.

arm: remove unnecessary armv9-a multilib variant [PR104144]

Remove the armv9-a specific multilib variants.  Instead, arrange to
use either the armv8-a multilibs or the armv7-a versions, depeding on
the configuration.  This eliminates the need to have a version of gas
that understands --march=armv9-a when building GCC.  Very little, if
anything in the standard libraries directly uses Armv9-a features
anyway.

Also remove the +crc variant rules for Armv9-a.  CRC is an implicit
part of Armv9-a, so doesn't have a explicit feature to handle it.

gcc/ChangeLog:

PR target/104144
* config/arm/t-aprofile (MULTI_ARCH_OPTS_A): Remove Armv9-a options.
(MULTI_ARCH_DIRS_A): Remove Armv9-a diretories.
(MULTILIB_REQUIRED): Don't require Armv9-a libraries.
(MULTILIB_MATCHES): Treat Armv9-a as equivalent to Armv8-a.
(MULTILIB_REUSE): Remove remap rules for Armv9-a.
* config/arm/t-multilib (v9_a_nosimd_variants): Delete.
(MULTILIB_MATCHES): Remove mappings for v9_a_nosimd_variants.

gcc/testsuite/ChangeLog:

PR target/104144
* gcc.target/arm/multilib.exp: Updated tests.

tree-optimization/105232 - handle overly large sizes in component_ref_size

The following properly checks tree_fits_poly_int64_p before converting
a size to a poly_int64.

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

PR tree-optimization/105232
* tree.cc (component_ref_size): Bail out for too large
or non-constant sizes.

tree-optimization/105226 - avoid splitting abnormal edges

Vectorizer loop versioning tries to version outer loops if possible
but fails to check whether it can actually split the single exit
edge as it will do.

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

PR tree-optimization/105226
* tree-vect-loop-manip.cc (vect_loop_versioning): Verify
we can split the exit of an outer loop we choose to version.

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

i386: i386-expand formatting fixes

While working on the PR105214 patch, I've noticed incorrect formatting
for a bunch of functions where the function names aren't at the start of
lines.

The following patch fixes it, though of course it isn't a regression.

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

* config/i386/i386-expand.cc (ix86_emit_i387_sinh, ix86_emit_i387_cosh,
ix86_emit_i387_tanh, ix86_emit_i387_asinh, ix86_emit_i387_acosh,
ix86_emit_i387_atanh, ix86_emit_i387_log1p, ix86_emit_i387_round,
ix86_emit_swdivsf, ix86_emit_swsqrtsf,
ix86_expand_atomic_fetch_op_loop, ix86_expand_cmpxchg_loop):
Formatting fix.
* config/i386/i386.cc (warn_once_call_ms2sysv_xlogues): Likewise.

i386: Fix ICE caused by ix86_emit_i387_log1p [PR105214]

The following testcase ICEs, because ix86_emit_i387_log1p attempts to
emit something like
  if (cond)
    some_code1;
  else
    some_code2;
and emits a conditional jump using emit_jump_insn (standard way in
the file) and an unconditional jump using emit_jump.
The problem with that is that if there is pending stack adjustment,
it isn't emitted before the conditional jump, but is before the
unconditional jump and therefore stack is adjusted only conditionally
(at the end of some_code1 above), which makes dwarf2 pass unhappy about it
but is a serious wrong-code even if it doesn't ICE.

This can be fixed either by emitting pending stack adjust before the
conditional jump as the following patch does, or by not using
  emit_jump (label2);
and instead hand inlining what that function does except for the
pending stack adjustment, like:
  emit_jump_insn (targetm.gen_jump (label2));
  emit_barrier ();
In that case there will be no stack adjustment in the sequence and
it will be done later on somewhere else.

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

PR target/105214
* config/i386/i386-expand.cc (ix86_emit_i387_log1p): Call
do_pending_stack_adjust.

* gcc.dg/asan/pr105214.c: New test.

builtins: Fix up expand_builtin_int_roundingfn_2 [PR105211]

The expansion of __builtin_iround{,f,l} etc. builtins in some cases
emits calls to a different fallback builtin.  To locate the right builtin
it uses mathfn_built_in_1 with the type of the first argument.
If its TYPE_MAIN_VARIANT is {float,double,long_double}_type_node, all is
fine, but on the following testcase, because GIMPLE considers scalar
float conversions between types with the same mode as useless,
TYPE_MAIN_VARIANT of the arg's type is float32_type_node and because there
isn't __builtin_lroundf32 returns NULL and we ICE.

This patch will first try the type of the first argument of the builtin's
prototype (so that say on sizeof(double)==sizeof(long double) target it honors
whether it was a *l or non-*l call; though even that can't be 100% trusted,
user could incorrectly prototype it) and as fallback the type argument.
If neither works, doesn't fallback.

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

PR rtl-optimization/105211
* builtins.cc (expand_builtin_int_roundingfn_2): If mathfn_built_in_1
fails for TREE_TYPE (arg), retry it with
TREE_VALUE (TYPE_ARG_TYPES (TREE_TYPE (fndecl))) and if even that
fails, emit call normally.

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

IBM zSystems: Add support for z16 as CPU name.

So far z16 was identified as arch14. After the machine has been
announced we can now add the real name.

gcc/ChangeLog:

* common/config/s390/s390-common.cc: Rename PF_ARCH14 to PF_Z16.
* config.gcc: Add z16 as march/mtune switch.
* config/s390/driver-native.cc (s390_host_detect_local_cpu):
Recognize z16 with -march=native.
* config/s390/s390-opts.h (enum processor_type): Rename
PROCESSOR_ARCH14 to PROCESSOR_3931_Z16.
* config/s390/s390.cc (PROCESSOR_ARCH14): Rename to ...
(PROCESSOR_3931_Z16): ... throughout the file.
(s390_processor processor_table): Add z16 as cpu string.
* config/s390/s390.h (enum processor_flags): Rename PF_ARCH14 to
PF_Z16.
(TARGET_CPU_ARCH14): Rename to ...
(TARGET_CPU_Z16): ... this.
(TARGET_CPU_ARCH14_P): Rename to ...
(TARGET_CPU_Z16_P): ... this.
(TARGET_ARCH14): Rename to ...
(TARGET_Z16): ... this.
(TARGET_ARCH14_P): Rename to ...
(TARGET_Z16_P): ... this.
* config/s390/s390.md (cpu_facility): Rename arch14 to z16 and
check TARGET_Z16 instead of TARGET_ARCH14.
* config/s390/s390.opt: Add z16 to processor_type.
* doc/invoke.texi: Document z16 and arch14.

c++: rodata and defaulted ctor [PR104142]

Trivial initialization shouldn't bump a variable out of .rodata; if the
result of build_aggr_init is an empty STATEMENT_LIST, throw it away.

PR c++/104142

gcc/cp/ChangeLog:

* decl.cc (check_initializer): Check TREE_SIDE_EFFECTS.

gcc/testsuite/ChangeLog:

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

c++: using operator= [PR105223]

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

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

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

gcc/cp/ChangeLog:

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

gcc/testsuite/ChangeLog:

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

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

gcc/ChangeLog:

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

Daily bump.

rs6000: Handle pcrel sibcalls to longcall functions [PR104894]

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

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

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

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

ipa: fix comment typos

gcc/ChangeLog:

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

c++: operator new lookup [PR98249]

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

PR c++/98249

gcc/cp/ChangeLog:

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

gcc/testsuite/ChangeLog:

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

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

libstdc++-v3/ChangeLog:

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

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

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

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

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

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

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

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

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

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

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

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

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

libstdc++-v3/ChangeLog:

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

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

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

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

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

libstdc++-v3/ChangeLog:

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

ppc: testsuite: require target effectively [PR104253]

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

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

for gcc/testsuite/ChangeLog

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

c++: Tolerate cdtors returning this in constexpr

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

for  gcc/cp/ChangeLog

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

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

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

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

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

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

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

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

for  gcc/cp/ChangeLog

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

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

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

gcc/ChangeLog:

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

libstdc++: Move stacktrace tests to 19_diagnostics directory

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

libstdc++-v3/ChangeLog:

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

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

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

libstdc++-v3/ChangeLog:

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

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

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

gcc/ChangeLog:

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

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

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

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

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

  _26 = ~_25;
  _43 = ~_44;

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

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

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

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

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

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

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

gcc/ChangeLog:

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

gcc/testsuite/ChangeLog:

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

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

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

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

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

PR c++/100370

gcc/cp/ChangeLog:

* init.cc (warn_placement_new_too_small): Check deref.

gcc/ChangeLog:

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

gcc/testsuite/ChangeLog:

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

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

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

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

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

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

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

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

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

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

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

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

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

[committed] Minor bfin codegen bugfix

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

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

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

PR testsuite/103196

gcc/testsuite/ChangeLog:

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

Daily bump.

Fortran: fix checking of coshape specification in ALLOCATE statement

gcc/fortran/ChangeLog:

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

gcc/testsuite/ChangeLog:

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

Daily bump.

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

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

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

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

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

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

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

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

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

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

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

Update semantic_interposition flag at analysis time

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

gcc/ChangeLog:

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

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

gcc/testsuite/ChangeLog:

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

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

Propagate nondeterministic and side_effects flags in modref summary after inlining

gcc/ChangeLog:

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

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

gcc/testsuite/ChangeLog:

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

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

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

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

gcc/testsuite/

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

loongarch: testsuite: skip builtin-apply2.c

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

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

gcc/testsuite/

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

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

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

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

gcc/cp/ChangeLog:

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

gcc/testsuite/ChangeLog:

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

c++: friend implicit template instantiation [PR91618]

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

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

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

gcc/cp/ChangeLog:

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

gcc/testsuite/ChangeLog:

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

Daily bump.

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

libstdc++-v3/ChangeLog:

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

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

libstdc++-v3/ChangeLog:

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

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

libstdc++-v3/ChangeLog:

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

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

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

gcc/ChangeLog:

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

tree-optimization/105198 - wrong code with predictive commoning

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

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

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

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

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

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

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

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

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

c: Error on va_arg with function type [PR105149]

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

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

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

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

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

fold-const: Fix up make_range_step [PR105189]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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