c++: FIX_TRUNC_EXPR in tsubst [PR102990]

This is a crash where a FIX_TRUNC_EXPR gets into tsubst_copy_and_build
where it hits gcc_unreachable ().

The history of tsubst_copy_and_build/FIX_TRUNC_EXPR is such that it
was introduced in r181478, but it did the wrong thing, whereupon it
was turned into gcc_unreachable () in r258821 (see this thread:
<https://gcc.gnu.org/pipermail/gcc-patches/2018-March/495853.html>).

In a template, we should never create a FIX_TRUNC_EXPR (that's what
conv_unsafe_in_template_p is for).  But in this test we are NOT in
a template when we call digest_nsdmi_init which ends up calling
convert_like, converting 1.0e+0 to int, so convert_to_integer_1
gives us a FIX_TRUNC_EXPR.

But then when we get to parsing f's parameters, we are in a template
when processing decltype(Helpers{}), and since r268321, when the
compound literal isn't instantiation-dependent and the type isn't
type-dependent, finish_compound_literal falls back to the normal
processing, so it calls digest_init, which does fold_non_dependent_init
and since the FIX_TRUNC_EXPR isn't dependent, we instantiate and
therefore crash in tsubst_copy_and_build.

The fateful call to fold_non_dependent_init comes from massage_init_elt,
We shouldn't be calling f_n_d_i on the result of get_nsdmi.  This we can
avoid by eschewing calling f_n_d_i on CONSTRUCTORs; their elements have
already been folded.

PR c++/102990

gcc/cp/ChangeLog:

* typeck2.cc (massage_init_elt): Avoid folding CONSTRUCTORs.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/nsdmi-template22.C: New test.
* g++.dg/cpp0x/nsdmi-template23.C: New test.

c++: missing SFINAE for non-constant consteval calls [PR104620]

Here we weren't respecting SFINAE when evaluating a call to a consteval
function, which caused us to reject the new testcase below.  This patch
fixes this by making build_over_call use the SFINAE-friendly version of
cxx_constant_value.

This change causes us to no longer diagnose ahead of time a couple of
non-constant non-dependent consteval calls in consteval-if2.C with
-fchecking=2.  These errors were apparently coming from the call to
fold_non_dependent_expr in build_non_dependent_expr (for the RHS of the +=)
despite complain=tf_none being passed.  Now that build_over_call respects
the value of complain during constant evaluation of a consteval call,
the errors are gone.

That the errors are also gone without -fchecking=2 is a regression caused
by r12-7264-gc19f317a78c0e4 and is the subject of PR104620.  As described
in comment #5, I think it's basically an accident that we were diagnosing
these two calls correctly before r12-7264, so perhaps we can live without
these errors for GCC 12.  Thus this patch just XFAILs the two tests.

PR c++/104620

gcc/cp/ChangeLog:

* call.cc (build_over_call): Use cxx_constant_value_sfinae
instead of cxx_constant_value to evaluate a consteval call.
* constexpr.cc (cxx_constant_value_sfinae): Add decl parameter
and pass it to cxx_eval_outermost_constant_expr.
* cp-tree.h (cxx_constant_value_sfinae): Add decl parameter.
* pt.cc (fold_targs_r): Pass NULL_TREE as decl parameter to
cxx_constant_value_sfinae.

gcc/testsuite/ChangeLog:

* g++.dg/cpp23/consteval-if2.C: XFAIL two dg-error tests where
the argument to the non-constant non-dependent consteval call is
wrapped by NON_DEPENDENT_EXPR.
* g++.dg/cpp2a/consteval30.C: New test.

hardened conditionals: drop copied identifiers

The copies of identifiers, indended to associate hardening SSA
temporaries to the original variables they refer to, end up causing
-fcompare-debug to fail, because DECL_UIDs are not identical, and the
nouid flag used in compare-debug dumps doesn't affect the uids in
naked identifiers, so the divergence becomes apparent.

This patch drops the naked identifiers.  Though somewhat desirable,
they're not necessary.

for  gcc/ChangeLog

PR debug/104564
* gimple-harden-conditionals.cc (detach_value): Keep temps
anonymous.

for  gcc/testsuite/ChangeLog

PR debug/104564
* c-c++-common/torture/harden-comp.c: Adjust.
* c-c++-common/torture/harden-cond.c: Adjust.

hardcmp: split before dispatch edge

If we harden a compare at the end of a block with an edge to the
abnormal dispatch block, it won't have a single successor.  Arrange to
split the block at its final stmt so as to have a single succ.

for  gcc/ChangeLog

PR middle-end/104975
* gimple-harden-conditionals.cc
(pass_harden_compares::execute): Force split in case of
multiple edges.

for  gcc/testsuite/ChangeLog

PR middle-end/104975
* gcc.dg/pr104975.c: New.

[libatomic] Fix return value in libat_test_and_set

On nvptx (using a Quadro K2000 with driver 470.103.01) I ran into this:
...
FAIL: gcc.dg/atomic/stdatomic-flag-2.c -O1 execution test
...
which mimimized to:
...
  #include <stdatomic.h>
  atomic_flag a = ATOMIC_FLAG_INIT;
  int main () {
    if ((atomic_flag_test_and_set) (&a))
      __builtin_abort ();
    return 0;
  }
...

The atomic_flag_test_and_set is implemented using __atomic_test_and_set_1,
which corresponds to the "word-sized compare-and-swap loop" version of
libat_test_and_set in libatomic/tas_n.c.

The semantics of a test-and-set is that the return value is "true if and only
if the previous contents were 'set'".

But the code uses:
...
  return woldval != 0;
...
which means it doesn't look only at the byte that was either set or not set,
but at the entire word.

Fix this by using instead:
...
  return (woldval & ((UTYPE) ~(UTYPE) 0 << shift)) != 0;
...

Tested on nvptx.

libatomic/ChangeLog:

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

PR target/105011
* tas_n.c (libat_test_and_set): Fix return value.

testsuite: Add compat.exp testcase for most common zero width bitfld ABI passing [PR102024]

On Tue, Mar 22, 2022 at 05:51:58PM +0100, Jakub Jelinek via Gcc wrote:
> I guess it would be nice to include the testcases we are talking about,
> like { float x; int : 0; float y; } and { float x; int : 0; } and
> { int : 0; float x; } into compat.exp testsuite so that we see ABI
> differences in compat testing.

Here is a patch that does that.  It uses the struct-layout-1* framework,
but isn't generated because we don't want in this case pseudo-random
structure layouts, but particular ones we know cause or could cause problems
on some targets.  If other problematic cases are discovered, we can add
further ones.

Tested on x86_64-linux with:
make check-gcc check-g++ RUNTESTFLAGS='ALT_CC_UNDER_TEST=gcc ALT_CXX_UNDER_TEST=g++ compat.exp=pr102*'
and with
make check-gcc check-g++ RUNTESTFLAGS='compat.exp=pr102*'
The former as expected has:
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
fails because on x86_64 we've changed the C ABI but kept the C++ ABI here.
E.g. on rs6000 it should be the g++.dg such tests to fail (all assuming
the alt gcc/g++ is GCC 4.5 through 11).

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

PR target/102024
* gcc.dg/compat/pr102024_main.c: New test.
* gcc.dg/compat/pr102024_test.h: New test.
* gcc.dg/compat/pr102024_x.c: New test.
* gcc.dg/compat/pr102024_y.c: New test.
* g++.dg/compat/pr102024_main.C: New test.
* g++.dg/compat/pr102024_test.h: New test.
* g++.dg/compat/pr102024_x.C: New test.
* g++.dg/compat/pr102024_y.C: New test.

fold-const: Handle C++ dependent COMPONENT_REFs in operand_equal_p [PR105035]

As mentioned in the PR, operand_equal_p already contains some hacks so that
it can be called already on pre-instantiation C++ trees from templates,
but the recent change to compare DECL_FIELD_OFFSET in the COMPONENT_REF
case broke this.  Many such COMPONENT_REFs are already punted on earlier
because they have NULL TREE_TYPE, but in this case the code knows what
type they have but still uses an IDENTIFIER_NODE as second operand
of COMPONENT_REF (I think SCOPE_REF is something that could be used too).

The following patch looks at those DECL_FIELD_*OFFSET fields only if
both field[01] args are FIELD_DECLs and otherwise keeps it to the
earlier OP_SAME (1) check that guards this whole block.

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

PR c++/105035
* fold-const.cc (operand_equal_p) <case COMPONENT_REF>: If either
field0 or field1 is not a FIELD_DECL, return false.

* g++.dg/warn/Wduplicated-cond2.C: New test.

Properly reset the port handle when closing

When the serial port is closed, we need to ensure that the port handle is
properly reset for it to be detected as closed.

gcc/ada/
PR ada/104767
* libgnat/g-sercom__mingw.adb (Close): Reset port handle to -1.
* libgnat/g-sercom__linux.adb (Close): Likewise.

Fix memory leaks

When changing the predcom pass to use auto_vec leaks were introduced by
failing to replace deallocation with C++ delete.  The following does
this.  It also fixes leaks in vectorization and range folding.

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

* tree-predcom.cc (chain::chain): Add CTOR.
(component::component): Likewise.
(pcom_worker::release_chain): Use delete.
(release_components): Likewise.
(pcom_worker::filter_suitable_components): Likewise.
(pcom_worker::split_data_refs_to_components): Use new.
(make_invariant_chain): Likewise.
(make_rooted_chain): Likewise.
(pcom_worker::combine_chains): Likewise.
* tree-vect-loop.cc (vect_create_epilog_for_reduction):
Make sure to release previously constructed scalar_results.
* tree-vect-stmts.cc (vectorizable_load): Use auto_vec
for vec_offsets.
* vr-values.cc (simplify_using_ranges::~simplify_using_ranges):
Release m_flag_set_edges.

tree-optimization/104970: Limit size computation for access attribute

Limit object size computation only to the simple case where access
attribute has been explicitly specified.  The object passed to
__builtin_dynamic_object_size could either be a pointer or a VLA whose
size has been described using access attribute.

Further, return a valid size only if the object is a void * pointer or
points to (or is a VLA of) a type that has a constant size.

gcc/ChangeLog:

PR tree-optimization/104970
* tree-object-size.cc (parm_object_size): Restrict size
computation scenarios to explicit access attributes.

gcc/testsuite/ChangeLog:

PR tree-optimization/104970
* gcc.dg/builtin-dynamic-object-size-0.c (test_parmsz_simple2,
test_parmsz_simple3, test_parmsz_extern, test_parmsz_internal,
test_parmsz_internal2, test_parmsz_internal3): New tests.
(main): Use them.

Signed-off-by: Siddhesh Poyarekar <siddhesh@gotplt.org>

c++: extern thread_local declarations in constexpr [PR104994]

C++14 to C++20 apparently should allow extern thread_local declarations in
constexpr functions, however useless they are there (because accessing
such vars is not valid in a constant expression, perhaps sizeof/decltype).
P2242 changed that for C++23 to passing through declaration but
https://cplusplus.github.io/CWG/issues/2552.html
has been filed for it yesterday.

The following patch implements the proposed wording of CWG 2552 in addition
to fixing the C++14 - C++20 handling bug.
If you'd like instead to keep the current pedantic C++23 wording for now,
that would mean taking out the first hunk (cxx_eval_constant_expression) and
g++.dg/cpp23/constexpr-nonlit2.C hunk.

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

PR c++/104994
* constexpr.cc (cxx_eval_constant_expression): Don't diagnose passing
through extern thread_local declarations.  Change wording from
declaration to definition.
(potential_constant_expression_1): Don't diagnose extern thread_local
declarations.  Change wording from declared to defined.
* decl.cc (start_decl): Likewise.

* g++.dg/diagnostic/constexpr1.C: Change expected diagnostic wording
from declared to defined.
* g++.dg/cpp23/constexpr-nonlit1.C: Likewise.
(garply): Change dg-error into dg-bogus.
* g++.dg/cpp23/constexpr-nonlit2.C: Change expected diagnostic wording
from declaration to definition.
* g++.dg/cpp23/constexpr-nonlit6.C: Change expected diagnostic wording
from declared to defined.
* g++.dg/cpp23/constexpr-nonlit7.C: New test.
* g++.dg/cpp2a/constexpr-try5.C: Change expected diagnostic wording
from declared to defined.
* g++.dg/cpp2a/consteval3.C: Likewise.

rs6000: Skip overload instances with NULL fntype [PR104967]

For some overload built-in function instance, if it requires
a data type which isn't defined on the target, its fntype
would be initialized as NULL.  This patch is to consider
this possibility in function find_instance, as shown in
PR104967.

PR target/104967

gcc/ChangeLog:

* config/rs6000/rs6000-c.cc (find_instance): Skip instances with null
function types.

Daily bump.

analyzer: fix accessing wrong stack frame on interprocedural return [PR104979]

PR analyzer/104979 reports a leak false positive when handling an
interprocedural return to a caller:

  LHS = CALL(ARGS);

where the LHS is a certain non-trivial compound expression.

The root cause is that parts of the LHS were being erroneously
evaluated with respect to the stack frame of the called function,
rather than tha of the caller.  When LHS contained a local variable
within the caller as part of certain nested expressions, this local
variable was looked for within the called frame, rather than that of the
caller.  This lookup in the wrong stack frame led to the local variable
being treated as uninitialized, and thus the write to LHS was considered
as writing to a garbage location, leading to the return value being
lost, and thus being considered as a leak.

The region_model code uses the analyzer's path_var class to try to
extend the tree type with stack depth information.  Based on the above,
I think that the path_var class is fundamentally broken, but it's used
in a few other places in the analyzer, so I don't want to rip it out
until the next stage 1.

In the meantime, this patch reworks how region_model::pop_frame works so
that the destination region for an interprocedural return value is
computed after the frame is popped, so that the region_model has the
stack frame for the *caller* at that point.  Doing so fixes the issue.

I attempted a more ambitious fix which moved the storing of the return
svalue into the destination region from region_model::pop_region into
region_model::update_for_return_gcall, with pop_frame returning the
return svalue.  Unfortunately, this regressed g++.dg/analyzer/pr93212.C,
which returns a pointer into a stale frame.
unbind_region_and_descendents and poison_any_pointers_to_descendents are
only set up to poison regions with bindings into the stale frame, not
individual svalues, and updating that became more invasive than I'm
comfortable with in stage 4.

The patch also adds assertions to verify that we have the correct
function when looking up locals/SSA names in a stack frame.  There
doesn't seem to be a general-purpose way to get at the function of an
SSA name, so the assertions go from SSA name to def-stmt to basic_block,
and from there use the analyzer's supergraph to get the function from
the basic_block.  If there's a simpler way to do this, please let me know.

gcc/analyzer/ChangeLog:
PR analyzer/104979
* engine.cc (impl_run_checkers): Create the engine after the
supergraph, and pass the supergraph to the engine.
* region-model.cc (region_model::get_lvalue_1): Pass ctxt to
frame_region::get_region_for_local.
(region_model::update_for_return_gcall): Pass the lvalue for the
result to pop_frame as a tree, rather than as a region.
(region_model::pop_frame): Update for above change, determining
the destination region after the frame is popped and thus with
respect to the caller frame rather than the called frame.
Likewise, set the value of the region to the return value after
the frame is popped.
(engine::engine): Add supergraph pointer.
(selftest::test_stack_frames): Set the DECL_CONTECT of PARM_DECLs.
(selftest::test_get_representative_path_var): Likewise.
(selftest::test_state_merging): Likewise.
* region-model.h (region_model::pop_frame): Convert first param
from a const region * to a tree.
(engine::engine): Add param "sg".
(engine::m_sg): New field.
* region.cc: Include "analyzer/sm.h" and
"analyzer/program-state.h".
(frame_region::get_region_for_local): Add "ctxt" param.
Add assertions that VAR_DECLs are locals, and that expr is for the
correct function.
* region.h (frame_region::get_region_for_local): Add "ctxt" param.

gcc/testsuite/ChangeLog:
PR analyzer/104979
* gcc.dg/analyzer/boxed-malloc-1-29.c: Deleted test, moving the
now fixed test_29 to...
* gcc.dg/analyzer/boxed-malloc-1.c: ...here.
* gcc.dg/analyzer/stale-frame-1.c: Add test coverage.

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

c++: tweak PR103337 fix

Patrick suggested a way to implement the designated-init handling without
(temporarily) modifying the CONSTRUCTOR being reshaped.

PR c++/103337

gcc/cp/ChangeLog:

* decl.cc (reshape_single_init): New.
(reshape_init_class): Use it.

c++: tweak PR105006 fix

Checking dependent_type_p avoids needing to walk the overloads in cases
where it would not be possible to find a dependent using.

PR c++/105006

gcc/cp/ChangeLog:

* name-lookup.cc (lookup_using_decl): Check that scope is
a dependent type before looking for dependent using.

Fortran: Fix directory stat check for '.' [PR103560]

MinGW does not like a call to 'stat' for './' via gfc_do_check_include_dir.
Solution: Only append '/' when concatenating the path with the filename.

gcc/fortran/ChangeLog:

PR fortran/103560
* scanner.cc (add_path_to_list): Don't append '/' to the
save include path.
(open_included_file): Use '/' in concatenating path + file name.
* module.cc (gzopen_included_file_1): Likewise.

gcc/testsuite/ChangeLog:

PR fortran/103560
* gfortran.dg/include_14.f90: Update dg-warning.
* gfortran.dg/include_17.f90: Likewise.
* gfortran.dg/include_18.f90: Likewise.
* gfortran.dg/include_6.f90: Update dg-*.

target/102125 - alternative memcpy folding improvement

The following extends the heuristical memcpy folding path with the
ability to use misaligned accesses on strict-alignment targets just
like the size-based path does.  That avoids regressing the following
testcase on arm

    uint64_t bar64(const uint8_t *rData1)
    {
        uint64_t buffer;
        memcpy(&buffer, rData1, sizeof(buffer));
        return buffer;
    }

when r12-3482-g5f6a6c91d7c592 is reverted.

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

PR target/102125
* gimple-fold.cc (gimple_fold_builtin_memory_op): Allow the
use of movmisalign when either the source or destination
decl is properly aligned.

rtl-optimization/105028 - fix compile-time hog in form_threads_from_copies

form_threads_from_copies processes a sorted array of copies, skipping
those with the same thread and conflicting threads and merging the
first non-conflicting ones.  After that it terminates the loop and
gathers the remaining elements of the array, skipping same thread
copies, re-starting the process.  For a large number of copies this
gathering of the rest takes considerable time and it also appears
pointless.  The following simply continues processing the array
which should be equivalent as far as I can see.

This takes form_threads_from_copies off the profile radar from
previously taking ~50% of the compile-time.

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

PR rtl-optimization/105028
* ira-color.cc (form_threads_from_copies): Remove unnecessary
copying of the sorted_copies tail.

c++: using from enclosing class template [PR105006]

Here, DECL_DEPENDENT_P was false for the second using because Row<eT> is
"the current instantiation", so lookup succeeds.  But since Row itself has a
dependent using-decl for operator(), the set of functions imported by the
second using is dependent, so we should set the flag.

PR c++/105006

gcc/cp/ChangeLog:

* name-lookup.cc (lookup_using_decl): Set DECL_DEPENDENT_P if lookup
finds a dependent using.

gcc/testsuite/ChangeLog:

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

analyzer: use tainted_allocation_size::m_mem_space [PR105017]

gcc/analyzer/ChangeLog:
PR analyzer/105017
* sm-taint.cc (taint_diagnostic::subclass_equal_p): Check
m_has_bounds as well as m_arg.
(tainted_allocation_size::subclass_equal_p): Chain up to base
class implementation.  Also check m_mem_space.
(tainted_allocation_size::emit): Add note showing stack-based vs
heap-based allocations.

gcc/testsuite/ChangeLog:
PR analyzer/105017
* gcc.dg/analyzer/taint-alloc-1.c: Add expected messages relating
to heap vs stack.

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

analyzer: fix ICE adding note to disabled diagnostic [PR104997]

gcc/analyzer/ChangeLog:
PR analyzer/104997
* diagnostic-manager.cc (diagnostic_manager::add_diagnostic):
Convert return type from "void" to "bool", reporting success vs
failure to caller, for both overloads.
* diagnostic-manager.h (diagnostic_manager::add_diagnostic):
Likewise.
* engine.cc (impl_region_model_context::warn): Propagate return
value from diagnostic_manager::add_diagnostic.

gcc/testsuite/ChangeLog:
PR analyzer/104997
* gcc.dg/analyzer/write-to-string-literal-4-disabled.c: New test,
adapted from write-to-string-literal-4.c.

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

libstdc++: Add missing constraints to std::bit_cast [PR105027]

Our std::bit_cast was relying on the compiler to check for errors inside
__builtin_bit_cast, instead of checking them as constraints. That means
std::bit_cast was not SFINAE-friendly.

This fix uses a requires-clause, so for old versions of Clang without
concepts support the function will still be unconstrained. At some point
in future we can remove the #ifdef __cpp_concepts check and rely on all
compilers having full concepts support in C++20 mode.

libstdc++-v3/ChangeLog:

PR libstdc++/105027
* include/std/bit (bit_cast): Add constraints.
* testsuite/26_numerics/bit/bit.cast/105027.cc: New test.

rs6000: Adjust error messages.

gcc/ChangeLog:

* config/rs6000/rs6000-c.cc (altivec_resolve_overloaded_builtin):
Use %qs in format.
* config/rs6000/rs6000.cc (rs6000_option_override_internal):
Reword the error message.

libstdc++: Fix feature test macros in <version> for freestanding

Some C++17 and C++20 feature test macros are only defined in <version>
for hosted builds, even though the features are supported for
freestanding.

All C++23 feature test macros are defined in <version> for freestanding,
but most of the features are only supported for hosted.

libstdc++-v3/ChangeLog:

* include/std/version [!_GLIBCXX_HOSTED]
(__cpp_lib_hardware_interference_size): Define for freestanding.
(__cpp_lib_bit_cast): Likewise.
(__cpp_lib_is_layout_compatible): Likewise.
(__cpp_lib_is_pointer_interconvertible): Likewise.
(__cpp_lib_adaptor_iterator_pair_constructor): Do not define for
freestanding.
(__cpp_lib_invoke_r): Likewise.
(__cpp_lib_ios_noreplace): Likewise.
(__cpp_lib_monadic_optional): Likewise.
(__cpp_lib_move_only_function): Likewise.
(__cpp_lib_spanstream): Likewise.
(__cpp_lib_stacktrace): Likewise.
(__cpp_lib_string_contains): Likewise.
(__cpp_lib_string_resize_and_overwrite): Likewise.
(__cpp_lib_to_underlying): Likewise.

libstdc++: Disable atomic wait for freestanding [PR105021]

We use either condition variables or futexes to implement atomic waits,
so we can't do it in freestanding. This is non-conforming, so should be
revisited later, probably by making freestanding atomic waiting
operations spin without ever blocking.

Reviewed-by: Thomas Rodgers <trodgers@redhat.com>
libstdc++-v3/ChangeLog:

PR libstdc++/105021
* include/bits/atomic_base.h [!_GLIBCXX_HOSTED]: Do not include
<bits/atomic_wait.h> for freestanding.

testsuite: Fix up sse2-v1ti-shift-3.c test [PR102986]

This test is dg-do run and invokes UB when these rotate functions
are called with 0 as second argument.  There are some other tests
that do this but they are dg-do compile only and not even call those
functions at all, so it IMHO doesn't matter that they are only well
defined for [1,127] and not [0,127].

The following patch fixes it, we pattern recognize both forms as rotates
and we emit identical assembly.

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

PR target/102986
* gcc.target/i386/sse2-v1ti-shift-3.c (rotr_v1ti, rotl_v1ti, rotr_ti,
rotl_ti): Use -i&127 instead of 128-i to avoid UB on i == 0.

LTO: Fixes for renaming issues with offload/OpenMP [PR104285]

gcc/lto/ChangeLog:

PR middle-end/104285
* lto-partition.cc (maybe_rewrite_identifier): Use get_identifier
for the returned string to be usable as hash key.
(validize_symbol_for_target): Hence, use return value directly.
(privatize_symbol_name_1): Track maybe_rewrite_identifier renames.
* lto.cc (offload_handle_link_vars): Move function up before ...
(do_whole_program_analysis): Call it after static renamings.
(lto_main): Move call after static renamings.

libgomp/ChangeLog:

PR middle-end/104285
* testsuite/libgomp.c++/target-same-name-2-a.C: New test.
* testsuite/libgomp.c++/target-same-name-2-b.C: New test.
* testsuite/libgomp.c++/target-same-name-2.C: New test.
* testsuite/libgomp.c-c++-common/target-same-name-1-a.c: New test.
* testsuite/libgomp.c-c++-common/target-same-name-1-b.c: New test.
* testsuite/libgomp.c-c++-common/target-same-name-1.c: New test.

Fix ICE caused by NULL_RTX returned by lowpart_subreg.

In validate_subreg, both (subreg:V2HF (reg:SI) 0)
and (subreg:V8HF (reg:V2HF) 0) are valid, but not
for (subreg:V8HF (reg:SI) 0) which causes ICE.

Ideally it should be handled in validate_subreg to support
subreg for all modes available in TARGET_CAN_CHANGE_MODE_CLASS, but
that would be too risky in stage4, so the patch is a walkround in the
backend to force_reg operands before lowpart_subreg for expanders or
pre_reload splitters.

gcc/ChangeLog:

PR target/104976
* config/i386/sse.md (ssePSmodelower): New.
(*avx_cmp<mode>3_ltint_not): Force_reg operand before
lowpart_subreg to avoid NULL_RTX.
(<avx512>_fmaddc_<mode>_mask1<round_expand_name>,
<avx512>_fcmaddc_<mode>_mask1<round_expand_name>,
fma_<mode>_fmaddc_bcst, fma_<mode>_fcmaddc_bcst,
<avx512>_<complexopname>_<mode>_mask<round_name>,
avx512fp16_fcmaddcsh_v8hf_mask1<round_expand_name>,
avx512fp16_fcmaddcsh_v8hf_mask3<round_expand_name>,
avx512fp16_fmaddcsh_v8hf_mask3<round_expand_name>,
avx512fp16_fmaddcsh_v8hf_mask3<round_expand_name>,
float<floatunssuffix><mode>v4hf2,
float<floatunssuffix>v2div2hf2,
fix<fixunssuffix>_truncv4hf<mode>2,
fix<fixunssuffix>_truncv2hfv2di2, extendv4hf<mode>2,
extendv2hfv2df2,
trunc<mode>v4hf2,truncv2dfv2hf2,
*avx512bw_permvar_truncv16siv16hi_1,
*avx512bw_permvar_truncv16siv16hi_1_hf,
*avx512f_permvar_truncv8siv8hi_1,
*avx512f_permvar_truncv8siv8hi_1_hf,
*avx512f_vpermvar_truncv8div8si_1,
*avx512f_permvar_truncv32hiv32qi_1,
*avx512f_permvar_truncv16hiv16qi_1,
*avx512f_permvar_truncv4div4si_1,
*avx512f_pshufb_truncv8hiv8qi_1,
*avx512f_pshufb_truncv4siv4hi_1,
*avx512f_pshufd_truncv2div2si_1,
sdot_prod<mode>, avx2_pblend<ssemodesuffix>_1,
ashrv2di3,ashrv2di3,usdot_prod<mode>): Ditto.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr104976.c: New test.
* gcc.target/i386/avx512fp16-vfcmaddcph-1a.c: Scan either
vblendps or masked vmovaps.
* gcc.target/i386/avx512fp16-vfmaddcph-1a.c: Ditto
* gcc.target/i386/avx512fp16vl-vfcmaddcph-1a.c: Ditto.
* gcc.target/i386/avx512fp16vl-vfmaddcph-1a.c: Ditto.

Daily bump.

libstdc++-v3 testsuite: Call fesetround(FE_DOWNWARD) only if defined

Without this, for a typical soft-float target such as cris-elf, after
commit r12-7676-g5a4e208022e704 you'll see, in libstdc++.log:
...
FAIL: 20_util/from_chars/6.cc (test for excess errors)
Excess errors:
/home/hp/tmp/auto0321/gcc/libstdc++-v3/testsuite/20_util/from_chars/6.cc:33: error: 'FE_DOWNWARD' was not declared in this scope

UNRESOLVED: 20_util/from_chars/6.cc compilation failed to produce executable
...

It appears to be a side-effect of that commit changing the
way __cpp_lib_to_chars is defined.  (On the bright side,
./7.cc now passes since that commit.)

TFM, specifically fenv(3), says that "Each of the macros
FE_DIVBYZERO, FE_INEXACT, FE_INVALID, FE_OVERFLOW,
FE_UNDERFLOW is defined when the implementation supports
handling of the corresponding exception".

A git-grep shows that this was the only place using a FE_ macro
unconditionally.

libstdc++-v3:
* testsuite/20_util/from_chars/6.cc (test01) [FE_DOWNWARD]:
Conditionalize call to fesetround.

c: -Wmissing-field-initializers and designated inits [PR82283, PR84685]

This patch fixes two kinds of wrong -Wmissing-field-initializers
warnings.  Our docs say that this warning "does not warn about designated
initializers", but we give a warning for

1) the array case:

  struct S {
    struct N {
      int a;
      int b;
    } c[1];
  } d = {
    .c[0].a = 1,
    .c[0].b = 1, // missing initializer for field 'b' of 'struct N'
  };

we warn because push_init_level, when constructing an array, clears
constructor_designated (which the warning relies on), and we forget
that we were in a designated initializer context.  Fixed by the
push_init_level hunk; and

2) the compound literal case:

  struct T {
    int a;
    int *b;
    int c;
  };

  struct T t = { .b = (int[]){1} }; // missing initializer for field 'c' of 'struct T'

where set_designator properly sets constructor_designated to 1, but the
compound literal causes us to create a whole new initializer_stack in
start_init, which clears constructor_designated.  Then, after we've parsed
the compound literal, finish_init flushes the initializer_stack entry,
but doesn't restore constructor_designated, so we forget we were in
a designated initializer context, which causes the bogus warning.  (The
designated flag is also tracked in constructor_stack, but in this case,
we didn't perform push_init_level between set_designator and start_init
so it wasn't saved anywhere.)

PR c/82283
PR c/84685

gcc/c/ChangeLog:

* c-typeck.cc (struct initializer_stack): Add 'designated' member.
(start_init): Set it.
(finish_init): Restore constructor_designated.
(push_init_level): Set constructor_designated to the value of
constructor_designated in the upper constructor_stack.

gcc/testsuite/ChangeLog:

* gcc.dg/Wmissing-field-initializers-1.c: New test.
* gcc.dg/Wmissing-field-initializers-2.c: New test.
* gcc.dg/Wmissing-field-initializers-3.c: New test.
* gcc.dg/Wmissing-field-initializers-4.c: New test.
* gcc.dg/Wmissing-field-initializers-5.c: New test.

Fortran: ensure intialization of stride array

gcc/fortran/ChangeLog:

PR fortran/104999
* simplify.cc (gfc_simplify_cshift): Ensure temporary holding
source array stride is initialized.

testsuite: Add testcase for already fixed PR [PR102489]

This got broken with r12-3529 and fixed with r12-5255.

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

PR c++/102489
* g++.dg/coroutines/pr102489.C: New test.

[nvptx] Use '%' as register prefix

The percentage sign as first character of a ptx identifier can be used to
avoid name conflicts, e.g., between user-defined variable names and
compiler-generated names.

The insn nvptx_uniform_warp_check contains register names without '%' prefix,
which potentially could lead to name conflicts with user-defined variable
names.

Fix this by adding a '%' prefix, more specifically a '%r_' prefix to avoid a
name conflict with ptx special registers.

Tested on x86_64 with nvptx accelerator.

gcc/ChangeLog:

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

PR target/104925
* config/nvptx/nvptx.md (define_insn "nvptx_uniform_warp_check"):
Use % as register prefix.

[nvptx] Limit HFmode support to mexperimental

With PR104489 still open and end-of-stage-4 approaching, classify HFmode
support as experimental, which is not enabled by default but can be enabled
using -mexperimental.

This fixes the nvptx build when the default sm_xx is set to sm_53 or higher.

Note that we're not using -mfp16 or some such, because that might create
expectations about being able to switch support on or off in the future, and
at this point it's not clear why, once reaching non-experimental status, it
shouldn't always be enabled.

gcc/ChangeLog:

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

* config/nvptx/nvptx.cc (nvptx_scalar_mode_supported_p)
(nvptx_libgcc_floating_mode_supported_p): Only enable HFmode for
mexperimental.

gcc/testsuite/ChangeLog:

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

* gcc.target/nvptx/float16-1.c: Add additional-options -mexperimental.
* gcc.target/nvptx/float16-2.c: Same.
* gcc.target/nvptx/float16-3.c: Same.
* gcc.target/nvptx/float16-4.c: Same.
* gcc.target/nvptx/float16-5.c: Same.
* gcc.target/nvptx/float16-6.c: Same.

[nvptx] Add mexperimental

Add new option -mexperimental.

This allows, rather than developing a new feature to completion in a
development branch, to develop a new feature on trunk, without disturbing
trunk.

The equivalent of the feature branch merge then becomes making the
functionality available for -mno-experimental.

If more features at the same time will be developed, we can do something like
-mexperimental=feature1,feature2 but for now that's not necessary.

For now, has no effect.

gcc/ChangeLog:

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

* config/nvptx/nvptx.opt (mexperimental): New option.

[nvptx] Use .alias directive for mptx >= 6.3

Starting with ptx isa version 6.3, a ptx directive .alias is available.
Use this directive to support symbol aliases, as far as possible.

The alias support is off by default.  It can be turned on using a switch
-malias.

Furthermore, for pre-sm_75, it's not effective unless the ptx version is
bumped to 6.3 or higher using -mptx (given that the default for pre-sm_75 is
6.0).

The alias support has the following limitations.

Only function aliases are supported.

Weak aliases are not supported.  That is, if I disable the check in
nvptx_asm_output_def_from_decls that disallows this, a weak alias is emitted
and parsed by the driver.  But the test gcc.dg/globalalias.c starts failing,
with the behaviour matching the comment about "weird behavior of AIX's .set
pseudo-op": a weak alias may resolve to different functions in different
files.

Aliases to weak symbols are not supported (see gcc.dg/localalias.c).  This is
currently not prohibited by the compiler, but with the driver link we run
into: "error: Function test with .weak scope cannot be aliased".

Aliases to aliases are not supported (see libgomp.c-c++-common/pr96390.c).
This is currently not prohibited by the compiler, but with the driver link we
run into:  "Internal error: alias to unknown symbol" .

Unreferenced aliases are not emitted (these can occur f.i. when inlining a
call to an alias).  This avoids driver link error "Internal error: reference
to deleted section".

When enabling malias by default, libgomp detects alias support and
consequently libgomp.a will contains a few uses of .alias.  This however
results in aforementioned "Internal error: reference to deleted section" in
many test-cases.  Either there's some error with how .alias is used, or
there's a driver bug.  While this issue is not resolved, we keep malias
off-by-default.

At some point we may add support in the nvptx-tools linker for symbol
aliases, and define f.i. malias=ptx and malias=ld to choose between the two in
the compiler.

An example of where this support is useful, is the OvO (OpenMP vs Offload)
testsuite.  The testsuite passes already at -O2.  But at -O0, there are errors
in some c++ test-cases due to missing symbol alias support.  By compiling with
-malias, the whole testsuite passes also at -O0.

This patch causes a regression:
...
-PASS: gcc.dg/pr60797.c  (test for errors, line 4)
+FAIL: gcc.dg/pr60797.c  (test for errors, line 4)
...
The test-case is skipped for effective target alias, and both without and with
this patch the nvptx target is considered to not support it, so the test-case is
executed.  The test-case expects an error message along the lines of "alias
definitions not supported in this configuration", but instead we run into:
...
gcc.dg/pr60797.c:4:12: error: foo aliased to undefined symbol
...
This is probably due to the fact that the nvptx backend now defines macros
ASM_OUTPUT_DEF and ASM_OUTPUT_DEF_FROM_DECLS, so from the point of view of the
common part of the compiler, aliases are supported.

gcc/ChangeLog:

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

PR target/104957
* config/nvptx/nvptx-protos.h (nvptx_asm_output_def_from_decls): Declare.
* config/nvptx/nvptx.cc (write_fn_proto_1): Don't add function marker
for alias.
(SET_ASM_OP, NVPTX_ASM_OUTPUT_DEF): New macro def.
(nvptx_asm_output_def_from_decls): New function.
* config/nvptx/nvptx.h (ASM_OUTPUT_DEF): New macro def, define to
gcc_unreachable ().
(ASM_OUTPUT_DEF_FROM_DECLS): New macro def, define to
nvptx_asm_output_def_from_decls.
* config/nvptx/nvptx.opt (malias): New opt.

gcc/testsuite/ChangeLog:

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

PR target/104957
* gcc.target/nvptx/alias-1.c: New test.
* gcc.target/nvptx/alias-2.c: New test.
* gcc.target/nvptx/alias-3.c: New test.
* gcc.target/nvptx/alias-4.c: New test.
* gcc.target/nvptx/nvptx.exp
(check_effective_target_runtime_ptx_isa_version_6_3): New proc.

[nvptx] Add warp sync at simt exit

Consider this code (with N defined to 1024):
...
  float v = 0.0;
  #pragma omp target map(tofrom: v)
  #pragma omp parallel for simd
  for (int i = 0 ; i < N; i++)
    {
      #pragma omp atomic update
      v = v + 1.0;
    }
...

It hangs when executing on target board unix/-foffload=-misa=sm_75, using
drivers 470.103.01 and 510.54 on a T400 board (sm_75).

I'm tentatively identifying the problem as a bug in -muniform-simt for
architectures that support Independent Thread Scheduling (sm_70 and later).

The problem -muniform-simt is trying to address is to make sure that a
register produced outside an openmp simd region is available when used in any
lane inside an simd region.

The solution is to, outside an simd region, execute in all warp lanes, thus
producing consistent values in result registers in each warp thread.

This approach doesn't work when executing in all warp lanes multiplies the
side effects from 1 to 32 separate side effects, which is the case for atomic
insns.  So atomic insns are rewritten to execute only in lane 0, and if
there are any results, those are propagated to the other threads in the warp.
[ And likewise for system calls malloc, free, vprintf. ]

Now, consider a non-atomic update: ld, add, store.  The store has side
effects, are those multiplied or not?

Pre-sm_70 we can assume that at the end of an SIMT region, any divergent
control flow has reconverged, and we have a uniform warp, executing in lock
step.  So:
- the load will load the same value into the result register across the warp,
- the add will write the same value into the result register across the warp,
- the store will write the same value to the same memory location, 32 times,
  at once, having the result of a single store.
So, no side-effect multiplication (well, at least that's the observation).

Starting sm_70, the threads in a warp are no longer guaranteed to reconverge
after divergence.  There's a "Convergence Optimizer" that can can identify
that it is safe for a warp to reconverge, but that works only as long as the
code does not contain "synchronizing operations".

Consequently, the ld, add, store sequence can be executed by a non-uniform
warp, which means the side effects can have multiplied, and the registers are
no longer guarantueed to be in sync.

The atomic update in the example above is translated using an atom.cas loop,
which means that we have divergence (because only one thread is allowed to
succeed at a time) and the "Convergence Optimizer" doesn't reconverge probably
because the atom.cas counts as a "synchronizing operation".  So, it seems
plausible that the root cause for the mentioned hang is the problem described
above.

Fix this by adding an explicit warp sync at simt exit.

Note that we're assuming here that the warp will stay uniform until the next
SIMT region entry.

Tested on x86_64 with nvptx accelerator.

gcc/ChangeLog:

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

PR target/104916
PR target/104783
* config/nvptx/nvptx.md (define_expand "omp_simt_exit"): Emit warp
sync (or uniform warp check for mptx < 6.0).

libgomp/ChangeLog:

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

PR target/104916
PR target/104783
* testsuite/libgomp.c/pr104783-2.c: New test.

tree-optimization/105012 - fix ICE from local DSE of if-conversion

The following guards dse_classify_store with the same condition as
the DSE pass does - availability of a virtual definition.  For
the PR we run into the fortran frontend generating a clobber for
a FUNCTION_DECL lhs which is ignored by the operand scanner and has
no virtual operands assigned.  Apart from fixing the frontend the
following fixes the ICE by adjusting if-conversion.

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

PR tree-optimization/105012
* tree-if-conv.cc (ifcvt_local_dce): Only call
dse_classify_store when we have a VDEF.

nvptx: fix wrapping in an error message.

PR target/104902

gcc/ChangeLog:

* config/nvptx/nvptx.cc (handle_ptx_version_option):
Fix option wrapping in an error message.

rs6000: wrap const in an error message.

PR target/104903

gcc/ChangeLog:

* config/rs6000/rs6000-c.cc (altivec_resolve_overloaded_builtin):
Wrap const keyword.

v850: fix typo in pragma name

      PR target/104904

gcc/ChangeLog:

* config/v850/v850-c.cc (pop_data_area): Fix typo in pragma
name.

rs6000: update error message format.

PR target/104898

gcc/ChangeLog:

* config/rs6000/rs6000.cc (rs6000_option_override_internal):
Use %qs instead of (%qs).

i386: update error message format.

Use '%qs' instead of '(%qs)'.

PR target/104898

gcc/ChangeLog:

* config/i386/i386-options.cc (ix86_option_override_internal):
  Use '%qs' instead of '(%qs)'.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr99753.c: Update test.
* gcc.target/i386/spellcheck-options-1.c: Likewise.
* gcc.target/i386/spellcheck-options-2.c: Likewise.
* gcc.target/i386/spellcheck-options-4.c: Likewise.

aarch64: update error message format.

Use 'qs' and remove usage '(%qs)'.

PR target/104898

gcc/ChangeLog:

* config/aarch64/aarch64.cc (aarch64_handle_attr_arch):
Use 'qs' and remove usage '(%qs)'.
(aarch64_handle_attr_cpu): Likewise.
(aarch64_handle_attr_tune): Likewise.
(aarch64_handle_attr_isa_flags): Likewise.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/branch-protection-attr.c:
Use 'qs' and remove usage '(%qs)'.
* gcc.target/aarch64/spellcheck_1.c: Likewise.
* gcc.target/aarch64/spellcheck_2.c: Likewise.
* gcc.target/aarch64/spellcheck_3.c: Likewise.

aarch64: Update regmove costs for neoverse-v1 and neoverse-512tvb tunings

This patch updates the register move tunings for
-mcpu/-mtune={neoverse-v1,neoverse-512tvb}.

gcc/ChangeLog:
2022-03-22  Tamar Christina  <tamar.christina@arm.com>
    Andre Vieira  <andre.simoesdiasvieira@arm.com>

* config/aarch64/aarch64.cc (neoversev1_regmove_cost): New tuning
struct.
(neoversev1_tunings): Use neoversev1_regmove_cost and update store_int
cost.
(neoverse512tvb_tunings): Likewise.

aarch64: Add Demeter tuning structs

This patch adds tuning structs for -mcpu/-mtune=demeter.

gcc/ChangeLog:

2022-03-22  Tamar Christina  <tamar.christina@arm.com>
    Andre Vieira  <andre.simoesdiasvieira@arm.com>

* config/aarch64/aarch64.cc (demeter_addrcost_table,
demeter_regmove_cost, demeter_advsimd_vector_cost,
demeter_sve_vector_cost, demeter_scalar_issue_info,
demeter_advsimd_issue_info, demeter_sve_issue_info,
demeter_vec_issue_info, demeter_vector_cost,
demeter_tunings): New tuning structs.
(aarch64_ve_op_count::rename_cycles_per_iter): Enable for demeter
tuning.
* config/aarch64/aarch64-cores.def: Add entry for demeter.
* config/aarch64/aarch64-tune.md (tune): Add demeter to list.

aarch64: Update reg-costs to differentiate between memmove costs

This patch introduces a struct to differentiate between different memmove costs
to enable a better modeling of memory operations. These have been modelled for
-mcpu/-mtune=neoverse-v1/neoverse-n1/neoverse-n2/neoverse-512tvb, for all other
tunings all entries are equal to the old single memmove cost to ensure the
behaviour remains the same.

2022-03-16  Tamar Christina  <tamar.christina@arm.com>
    Andre Vieira  <andre.simoesdiasvieira@arm.com>

gcc/ChangeLog:

* config/aarch64/aarch64-protos.h (struct cpu_memmov_cost): New struct.
(struct tune_params): Change type of memmov_cost to use cpu_memmov_cost.
* config/aarch64/aarch64.cc (aarch64_memory_move_cost): Update all
tunings to use cpu_memmov_cost struct.

aarch64: Add Neoverse-N2 tuning structs

This patch adds tuning structures for Neoverse N2.

2022-03-22  Tamar Christina  <tamar.christina@arm.com>
    Andre Vieira  <andre.simoesdiasvieira@arm.com>

* config/aarch64/aarch64.cc (neoversen2_addrcost_table,
neoversen2_regmove_cost, neoversen2_advsimd_vector_cost,
neoversen2_sve_vector_cost, neoversen2_scalar_issue_info,
neoversen2_advsimd_issue_info, neoversen2_sve_issue_info,
neoversen2_vec_issue_info, neoversen2_tunings): New structs.
(neoversen2_tunings): Use new structs and update tuning flags.
(aarch64_vec_op_count::rename_cycles_per_iter): Enable for neoversen2
tuning.

aarch64: Enable FP16 feature by default for Armv9

This patch adds the feature bit for FP16 to the feature set for Armv9 since
Armv9 requires SVE to be implemented and SVE requires FP16 to be implemented.

2022-03-22  Andre Vieira  <andre.simoesdiasvieira@arm.com>

* config/aarch64/aarch64.h (AARCH64_FL_FOR_ARCH9): Add FP16 feature
bit.

lto-plugin: Use GNU ld or Solaris ld version script in preference to -export-symbols-regex [PR102426]

As reported, libtool -export-symbols-regex doesn't work on Solaris
when using GNU ld instead of Sun ld, libtool just always assumes Sun ld.
As I'm unsure what is the maintainance status of libtool right now,
this patch solves it on the lto-plugin side instead, tests at configure time
similar way how libssp and other target libraries test for symbol versioning
(except omitting the symbol version because we just want one GLOBAL symbol
and rest of them LOCAL), and will use the current way of
-export-symbols-regex onload as fallback when this doesn't work.

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

PR lto/102426
lto-plugin/
* configure.ac (LTO_PLUGIN_USE_SYMVER, LTO_PLUGIN_USE_SYMVER_GNU,
LTO_PLUGIN_USE_SYMVER_SUN): New test for symbol versioning support.
* Makefile.am (version_arg, version_dep): Set conditionally based
on LTO_PLUGIN_USE_SYMVER*.
(liblto_plugin_la_LDFLAGS): Use $(version_arg) instead of
-export-symbols-regex onload.
(liblto_plugin_la_DEPENDENCIES): Depend on $(version_dep).
* lto-plugin.map: New file.
* configure: Regenerated.
* Makefile.in: Regenerated.

Extend splitter pattern to reversed condition by swapping then and else rtx. [PR target/104982]

Failed to match this instruction:
(set (reg/v:SI 88 [ z ])
    (if_then_else:SI (eq (zero_extract:SI (reg:SI 92)
                (const_int 1 [0x1])
                (zero_extend:SI (subreg:QI (reg:SI 93) 0)))
            (const_int 0 [0]))
        (reg:SI 95)
        (reg:SI 94)))

but it's equal to

(set (reg/v:SI 88 [ z ])
    (if_then_else:SI (ne (zero_extract:SI (reg:SI 92)
                (const_int 1 [0x1])
                (zero_extend:SI (subreg:QI (reg:SI 93) 0)))
            (const_int 0 [0]))
        (reg:SI 94)
        (reg:SI 95)))

which is the exact existing splitter.

The patch will fix below regressions:

On x86-64, r12-7687 caused:

FAIL: gcc.target/i386/bt-5.c scan-assembler-not sar[lq][ \t]
FAIL: gcc.target/i386/bt-5.c scan-assembler-times bt[lq][ \t] 7

gcc/ChangeLog:

PR target/104982
* config/i386/i386.md (*jcc_bt<mode>_mask): Extend the
following splitter to reversed condition.

testsuite: Add testcase for no longer failing PR [PR102645]

This test started ICEing with r12-3876 but stopped with r12-5264.

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

PR tree-optimization/102645
* gcc.c-torture/compile/pr102645.c: New test.

calls: Fix error recovery after sorry differently [PR104989]

On Mon, Feb 28, 2022 at 07:52:56AM -0000, Roger Sayle wrote:
> This patch resolves PR c++/84964 which is an ICE in the middle-end after
> emitting a "sorry, unimplemented" message, and is a regression from
> earlier releases of GCC.  This issue is that after encountering a
> function call requiring an unreasonable amount of stack space, the
> code continues and falls foul of an assert checking that stack pointer
> has been correctly updated.  The fix is to (locally) consider aborted
> function calls as "no return", which skips this downstream sanity check.

As can be seen on PR104989, just setting ECF_NORETURN after sorry is quite
risky and leads to other ICEs.  The problem is that ECF_NORETURN calls
better should be at the end of basic blocks that don't have any fallthru
successor edges, otherwise we can ICE later.

This patch instead sets sibcall_failure if in pass == 0 (sibcall_failure
means that the tail call sequence is not useful/not desirable and throws
it away) and otherwise sets a new bool variable that will let us pass
the assertion and also throws away the whole call sequence, I think that is
best for error recovery.

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

PR rtl-optimization/104989
* calls.cc (expand_call): Don't set ECF_NORETURN in flags after
sorry for passing too large argument, instead set sibcall_failure
for pass == 0, or a new normal_failure flag otherwise.  If
normal_failure is set, don't assert all stack has been deallocated
at the end and throw away the whole insn sequence.

* g++.dg/other/pr104989.C: New test.

print-tree:Avoid warnings of overflow

This patch avoids two warnings of "'sprintf' may write a
terminating nul past the end of the destination
[-Wformat-overflow=]" when build GCC.

Tested on x86_64, and committed as obvious.

gcc/ChangeLog:

* print-tree.cc: Change array length

AVX512FP16: Fix wrong code for _mm_mask_f[c]madd.*sch [PR 104978]

For complex scalar intrinsic like _mm_mask_fcmadd_sch, the
mask should be and by 1 to ensure the mask is bind to lowest byte.
Use masked vmovss to perform same operation which omits higher bits
of mask.

gcc/ChangeLog:

PR target/104978
* config/i386/sse.md
(avx512fp16_fmaddcsh_v8hf_mask1<round_expand_name):
Use avx512f_movsf_mask instead of vmovaps or vblend, and
force_reg before lowpart_subreg.
(avx512fp16_fcmaddcsh_v8hf_mask1<round_expand_name): Likewise.

gcc/testsuite/ChangeLog:

PR target/104978
* gcc.target/i386/avx512fp16-vfcmaddcsh-1a.c: Adjust asm scan.
* gcc.target/i386/avx512fp16-vfmaddcsh-1a.c: Ditto.
* gcc.target/i386/avx512fp16-vfcmaddcsh-1c.c: Removed.
* gcc.target/i386/avx512fp16-vfmaddcsh-1c.c: Ditto.
* gcc.target/i386/pr104978.c: New test.

Daily bump.

x86: Disable SSE in ISA2 for -mgeneral-regs-only

Replace OPTION_MASK_ISA2_AVX512F_UNSET with OPTION_MASK_ISA2_SSE_UNSET
in OPTION_MASK_ISA2_GENERAL_REGS_ONLY_UNSET to disable SSE, AVX and
AVX512 ISAs.

gcc/

PR target/105000
* common/config/i386/i386-common.cc
(OPTION_MASK_ISA2_GENERAL_REGS_ONLY_UNSET): Replace
OPTION_MASK_ISA2_AVX512F_UNSET with OPTION_MASK_ISA2_SSE_UNSET.

gcc/testsuite/

PR target/105000
* gcc.target/i386/pr105000-1.c: New test.
* gcc.target/i386/pr105000-2.c: Likewise.
* gcc.target/i386/pr105000-3.c: Likewise.
* gcc.target/i386/pr105000-4.c: Likewise.

c++: initialized array of vla [PR58646]

We went into build_vec_init because we're dealing with a VLA, but then
build_vec_init thought it was safe to just build an INIT_EXPR because the
outer dimension is constant.  Nope.

PR c++/58646

gcc/cp/ChangeLog:

* init.cc (build_vec_init): Check for vla element type.

gcc/testsuite/ChangeLog:

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

x86: Disable AVX on pr86722.c and pr90356.c

SSE/SSE2 are enabled explicitly on pr86722.c and pr90356.c.  Disable AVX
to avoid AVX with -march=native.

PR target/86722
PR tree-optimization/90356
* gcc.target/i386/pr86722.c: Add -mno-avx.
* gcc.target/i386/pr90356.c: Likewise.

x86: Properly check FEATURE_AESKLE

1. Pass 0x19 to __cpuid for bit_AESKLE.
2. Enable FEATURE_AESKLE only if bit_AESKLE is set.

PR target/104998
* common/config/i386/cpuinfo.h (get_available_features): Pass
0x19 to __cpuid for bit_AESKLE.  Enable FEATURE_AESKLE only if
bit_AESKLE is set.

c++: designated init and aggregate members [PR103337]

Our C++20 designated initializer handling was broken with members of class
type; we would find the relevant member and then try to find a member of
the member with the same name.  Or we would sometimes ignore the designator
entirely.  The former problem is fixed by the change to reshape_init_class,
the latter by the change to reshape_init_r.

PR c++/103337
PR c++/102740
PR c++/103299
PR c++/102538

gcc/cp/ChangeLog:

* decl.cc (reshape_init_class): Avoid looking for designator
after we found it.
(reshape_init_r): Keep looking for designator.

gcc/testsuite/ChangeLog:

* g++.dg/ext/flexary3.C: Remove one error.
* g++.dg/parse/pr43765.C: Likewise.
* g++.dg/cpp2a/desig22.C: New test.
* g++.dg/cpp2a/desig23.C: New test.
* g++.dg/cpp2a/desig24.C: New test.
* g++.dg/cpp2a/desig25.C: New test.

c++: designator and anon struct [PR101767]

We found .x in the anonymous struct, but then didn't find .y there; we
should decide that means we're done with the struct rather than that the
code is wrong.

PR c++/101767

gcc/cp/ChangeLog:

* decl.cc (reshape_init_class): Back out of anon struct
if a designator doesn't match.

gcc/testsuite/ChangeLog:

* g++.dg/ext/anon-struct10.C: New test.

Update gcc sv.po

* sv.po: Update.

d: Fix internal compiler error: in build_complex, at tree.c:2358

The conversion from the special _Complex enum to native complex used
build_complex, however the input value isn't necessarily a literal.

PR d/105004

gcc/d/ChangeLog:

* d-codegen.cc (build_struct_literal): Use complex_expr to build
complex expressions from __c_complex types.

gcc/testsuite/ChangeLog:

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

d: Merge upstream dmd 2503f17e5, phobos a74fa63e6.

D front-end changes:

    - Import dmd mainline development.
    - Removed internal d_intN and d_unsN aliases to stdint types, which
      caused a regression on Solaris where int8_t is a char (PR104911).

Phobos changes:

    - Import phobos mainline development.

PR d/104911

gcc/d/ChangeLog:

* dmd/MERGE: Merge upstream dmd 2503f17e5.
* d-convert.cc (convert_expr): Replace d_uns64 with dinteger_t.
* d-lang.cc: Remove dmd/root/file.h include.
(d_handle_option): Update for new front-end interface.
(d_parse_file): Likewise.

libphobos/ChangeLog:

* src/MERGE: Merge upstream phobos a74fa63e6.

rtl-ssa: Fix prev/next_def confusion [PR104869]

rtl-ssa chains definitions into an RPO list.  It also groups
sequences of clobbers together into a single node, so that it's
possible to skip over the clobbers in constant time in order to
get the next or previous set.

When adding a clobber to an insn, the main DF barriers for that
clobber are the last use of the previous set (if any) and the next
set (if any); adding a new clobber to a sea of clobbers is fine.
def_lookup provided the basis for these barriers as prev_def ()
and next_def ().

But of course, in hindsight, those were bad names, since they
implied that the returned values were literally the previous
definition (of any kind) or the next definition (of any kind).
And function_info::make_use_available was using the same routines
assuming that they had that meaning. :-(

This made a difference for the case where the start of a BB
occurs in the middle of an (RPO) clobber group: we then want
the previous and next clobbers in the group, rather than the
set before the clobber group and the set after the clobber group.

This patch renames the existing routines to something that's hopefully
clearer (though also more long-winded).  It then adds routines that
really do provide the previous and next definitions.

This complication is supposed to be internal to rtl-ssa and, as
mentioned above, is part of trying to reduce time complexity.

gcc/
PR middle-end/104869
* rtl-ssa/accesses.h (clobber_group::prev_clobber): Declare.
(clobber_group::next_clobber): Likewise.
(def_lookup::prev_def): Rename to...
(def_lookup::last_def_of_prev_group): ...this.
(def_lookup::next_def): Rename to...
(def_lookup::first_def_of_next_group): ...this.
(def_lookup::matching_or_prev_def): Rename to...
(def_lookup::matching_set_or_last_def_of_prev_group): ...this.
(def_lookup::matching_or_next_def): Rename to...
(def_lookup::matching_set_or_first_def_of_next_group): ...this.
(def_lookup::prev_def): New function, taking the lookup insn as
argument.
(def_lookup::next_def): Likewise.
* rtl-ssa/member-fns.inl (def_lookup::prev_def): Rename to...
(def_lookup::last_def_of_prev_group): ...this.
(def_lookup::next_def): Rename to...
(def_lookup::first_def_of_next_group): ...this.
(def_lookup::matching_or_prev_def): Rename to...
(def_lookup::matching_set_or_last_def_of_prev_group): ...this.
(def_lookup::matching_or_next_def): Rename to...
(def_lookup::matching_set_or_first_def_of_next_group): ...this.
* rtl-ssa/movement.h (restrict_movement_for_dead_range): Update after
above renaming.
* rtl-ssa/accesses.cc (clobber_group::prev_clobber): New function.
(clobber_group::next_clobber): Likewise.
(def_lookup::prev_def): Likewise.
(def_lookup::next_def): Likewise.
(function_info::make_use_available): Pass the lookup insn to
def_lookup::prev_def and def_lookup::next_def.

gcc/testsuite/
PR middle-end/104869
* g++.dg/pr104869.C: New test.

Avoid a warning of overflow

This patch avoid a warning of "c-ada-spec.cc:1660:34: warning:
'sprintf' may write a terminating nul past the end of the
destination [-Wformat-overflow=]" when build GCC.

gcc/c-family/ChangeLog:

* c-ada-spec.cc: Change array length

libstdc++: Work around clang misdesign in time_get<>::get [PR104990]

Apparently clang has a -fgnuc-version= option which allows it to pretend
it is any GCC version the user likes.  It is already bad that it claims to
be GCC 4.2 compatible by default when it is not (various unimplemented
extensions at least), but this option is a horrible idea.

Anyway, this patch adds a hack for it.

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

PR libstdc++/104990
* include/bits/locale_facets_nonio.tcc (get): Don't check if do_get
isn't overloaded if __clang__ is defined.

docs: Document min-pagesize parameter.

gcc/ChangeLog:

* doc/invoke.texi: Document min-pagesize parameter.

Dump when estimating the number of iterations of a loop

Currently the dumps are somewhat inter-mangled, not showing the
(possibly bad) recursion between niter estimation and number of
iteration computation.  The following tries to improve deciphering
a little bit by dumping when we do niter estimation.

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

* tree-ssa-loop-niter.cc (estimate_numbers_of_iterations): Dump
we are estimating niter of loop.

RISC-V: Implement misc macro for vector extensions.

See also:
https://github.com/riscv-non-isa/riscv-c-api-doc/pull/21

gcc/ChangeLog:

* common/config/riscv/riscv-common.cc (riscv_ext_flag_table):
Update flag name and mask name.
* config/riscv/riscv-c.cc (riscv_cpu_cpp_builtins): Define
misc macro for vector extensions.
* config/riscv/riscv-opts.h (MASK_VECTOR_EEW_32): Rename to ...
(MASK_VECTOR_ELEN_32): ... this.
(MASK_VECTOR_EEW_64): Rename to ...
(MASK_VECTOR_ELEN_64): ... this.
(MASK_VECTOR_EEW_FP_32): Rename to ...
(MASK_VECTOR_ELEN_FP_32): ... this.
(MASK_VECTOR_EEW_FP_64): Rename to ...
(MASK_VECTOR_ELEN_FP_64): ... this.
(TARGET_VECTOR_ELEN_32): New.
(TARGET_VECTOR_ELEN_64): Ditto.
(TARGET_VECTOR_ELEN_FP_32): Ditto.
(TARGET_VECTOR_ELEN_FP_64): Ditto.
(TARGET_MIN_VLEN): Ditto.
* config/riscv/riscv.opt (riscv_vector_eew_flags): Rename to ...
(riscv_vector_elen_flags): ... this.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/arch-13.c: New.
* gcc.target/riscv/arch-14.c: Ditto.
* gcc.target/riscv/arch-15.c: Ditto.
* gcc.target/riscv/predef-18.c: Ditto.
* gcc.target/riscv/predef-19.c: Ditto.
* gcc.target/riscv/predef-20.c: Ditto.

AVX512FP16: Fix masm=intel output for vfc?(madd|mul)csh [PR 104977]

Fix typo in subst for scalar complex mask_round operand.

gcc/ChangeLog:

PR target/104977
* config/i386/sse.md
(avx512fp16_fma<complexopname>sh_v8hf<mask_scalarcz_name><round_scalarcz_name>):
Correct round operand for intel dialect.

gcc/testsuite/ChangeLog:

PR target/104977
* gcc.target/i386/pr104977.c: New test.

Daily bump.

Fix testsuite fallout from pr104960 change

Recent changes twiddled the output for s390/arch13/sel-1.c causing testsuite failures.  As far as I can tell both sequences are equivalent from a performance standpoint.   This patch changes the test to accept both forms.

gcc/testsuite
* gcc.target/s390/arch13/sel-1.c: Adjust expected output.

Daily bump.

fortran: Separate associate character lengths earlier [PR104570]

This change workarounds an ICE in the evaluation of the character length
of an array expression referencing an associate variable; the code is
not prepared to see a non-scalar expression as it doesn’t initialize the
scalarizer.

Before this change, associate length symbols get a new gfc_charlen at
resolution stage to unshare them from the associate expression, so that
at translation stage it is a decl specific to the associate symbol that
is initialized, not the decl of some other symbol.  This
reinitialization of gfc_charlen happens after expressions referencing
the associate symbol have been parsed, so that those expressions retain
the original gfc_charlen they have copied from the symbol.
At translation stage, the gfc_charlen for the associate symbol is setup
with the decl holding the actual length value, but the expressions have
retained the original gfc_charlen without any decl.  So they need to
evaluate the character length, and this is where the ICE happens.

This change moves the reinitialization of gfc_charlen earlier at parsing
stage, so that at resolution stage the gfc_charlen can be retained as
it’s already not shared with any other symbol, and the expressions which
now share their gfc_charlen with the symbol are automatically updated
when the length decl is setup at translation stage.  There is no need
any more to evaluate the character length as it has all the required
information, and the ICE doesn’t happen.

The first resolve.cc hunk is necessary to avoid regressing on the
associate_35.f90 testcase.

PR fortran/104228
PR fortran/104570

gcc/fortran/ChangeLog:

* parse.cc (parse_associate): Use a new distinct gfc_charlen if the
copied type has one whose length is not known to be constant.
* resolve.cc (resolve_assoc_var): Reset charlen if it’s shared with
the associate target regardless of the expression type.
Don’t reinitialize charlen if it’s deferred.

gcc/testsuite/ChangeLog:

* gfortran.dg/associate_58.f90: New test.

libgcc: m68k: avoid TEXTRELs in shared library (PR 86224)

libgcc/
PR libgcc/86224
* config/m68k/lb1sf68.S (__mulsi3_internal): Internal, hidden alias
for __mulsi3.
(__udivsi3_internal, __divsi3_internal): Similarly.
(__umodsi3, __modsi3): Use the internal function names.

selftest: Move C-specific tests to c_family

When trying to make use of the selftest framework over on the rust
frontend, we ran into issues where rust1 was expected to produce errors
containing C-like type names such as `int`.

I had gotten in contact with David Malcolm on the gcc mailing list [1],
who advised moving some test functions to a better location. The
offending functions have also been renamed in order to better fit the C
family of tests, and are thus not called when performing general
selftests anymore.

Kindly,

[1]: https://gcc.gnu.org/pipermail/gcc/2021-November/237703.html

2022-02-16 Arthur Cohen <arthur.cohen@embecosm.com>

gcc/c-family/

* c-common.cc (c_family_tests): Call the new tests.
* c-common.h (c_diagnostic_tests): Declare.
(c_opt_problem_cc_tests): Likewise.

gcc/
* diagnostic.cc (diagnostic_cc_tests): Rename to...
(c_diagnostic_cc_tests): ...this.
* opt-problem.cc (opt_problem_cc_tests): Rename to...
(c_opt_problem_cc_tests): ...this.
* selftest-run-tests.cc (selftest::run_tests): No longer run
opt_problem_cc_tests or diagnostic_cc_tests.
* selftest.h (diagnostic_cc_tests): Remove declaration.
(opt_problem_cc_tests): Likewise.

[PATCH] gcc: pass-manager: Fix memory leak. [PR jit/63854]

Before the patch, compiling the hello world example of libgccjit with
the external driver under Valgrind shows a loss of 12,611 (48 direct)
bytes.  After the patch, no memory leaks are reported anymore.
(Memory leaks occurring when using the internal driver are mostly in
the driver code in gcc/gcc.c and have to be fixed separately.)

The patch has been tested by fully bootstrapping the compiler with the
frontends C, C++, Fortran, LTO, ObjC, JIT and running the test suite
under a x86_64-pc-linux-gnu host.

gcc/ChangeLog:

PR jit/63854
* hash-traits.h (struct typed_const_free_remove): New.
(struct free_string_hash): New.
* pass_manager.h: Use free_string_hash.
* passes.cc (pass_manager::register_pass_name): Use free_string_hash.
(pass_manager::~pass_manager): Delete allocated m_name_to_pass_map.

rename floatformat_ia64_quad_{big, little} to floatformat_ieee_quad_{big, little}

I submitted a GDB patch [1] to rename floatformats_ia64_quad to
floatformats_ieee_quad to reflect the reality, and then we can
clean up the related code.

As GDB Global Maintainer Tom Tromey said [2]:

  These files are maintained in gcc and then imported into the
  binutils-gdb repository, so any changes to them will have to
  be proposed there first.

this GCC patch is preparation for the GDB patch, no functionality
change.

[1] https://sourceware.org/pipermail/gdb-patches/2022-March/186452.html
[2] https://sourceware.org/pipermail/gdb-patches/2022-March/186569.html

Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
include/
* floatformat.h (floatformat_ieee_quad_big): Renamed from
floatformat_ia64_quad_big.
(floatformat_ieee_quad_little): Similarly.

libiberty/
* floatformat.c (floatformat_ieee_quad_big): Renamed from
floatformat_ia64_quad_big.
(floatformat_ieee_quad_little): Similarly.

i386: Don't emit pushf;pop for __builtin_ia32_readeflags_u* with unused lhs [PR104971]

__builtin_ia32_readeflags_u* aren't marked const or pure I think
intentionally, so that they aren't CSEd from different regions of a function
etc. because we don't and can't easily track all dependencies between
it and surrounding code (if somebody looks at the condition flags, it is
dependent on the vast majority of instructions).
But the builtin itself doesn't have any side-effects, so if we ignore the
result of the builtin, there is no point to emit anything.

There is a LRA bug that miscompiles the testcase which this patch makes
latent, which is certainly worth fixing too, but IMHO this change
(and maybe ix86_gimple_fold_builtin too which would fold it even earlier
when it looses lhs) is worth it as well.

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

PR middle-end/104971
* config/i386/i386-expand.cc
(ix86_expand_builtin) <case IX86_BUILTIN_READ_FLAGS>: If ignore,
don't push/pop anything and just return const0_rtx.

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

c-family: Fix up ICE during pretty-printing of PMF related expression [PR101515]

The intent of r11-6729 is that it prints something that helps user to figure
out what exactly is being accessed.
When we find a unique non-static data member that is being accessed, even
when we can't fold it nicely, IMNSHO it is better to print
  ((sometype *)&var)->field
or
  (*(sometype *)&var).field
instead of
  *(fieldtype *)((char *)&var + 56)
because the user doesn't know what is at offset 56, we shouldn't ask user
to decipher structure layout etc.

One question is if we could return something better for the TYPE_PTRMEMFUNC_FLAG
RECORD_TYPE members here (something that would print it more naturally/readably
in a C++ way), though the fact that the routine is in c-family makes it
harder.

Another one is whether we shouldn't punt for FIELD_DECLs that don't have
nicely printable name of its containing scope, something like:
                if (tree scope = get_containing_scope (field))
                  if (TYPE_P (scope) && TYPE_NAME (scope) == NULL_TREE)
                    break;
                return cop;
or so.  This patch implements that.

Note the returned cop is a COMPONENT_REF where the first argument has a
nicely printable type name (x with type sp), but sp's TYPE_MAIN_VARIANT
is the unnamed TYPE_PTRMEMFUNC_FLAG.  So another possibility would be if
we see such a problem for the FIELD_DECL's scope, check if TYPE_MAIN_VARIANT
of the first COMPONENT_REF's argument is equal to that scope and in that
case use TREE_TYPE of the first COMPONENT_REF's argument as the scope
instead.

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

PR c++/101515
* c-pretty-print.cc (c_fold_indirect_ref_for_warn): For C++ don't
return COMPONENT_REFs with FIELD_DECLs whose containing scope can't
be printed.

* g++.dg/warn/pr101515.C: New test.

Daily bump.

analyzer: extend state-purging to locals [PR104943]

The existing analyzer code attempts to purge the state of SSA names
where it can in order to minimize the size of program_state instances,
and to increase the chances of being able to reuse exploded_node
instances whilst exploring the user's code.

PR analyzer/104943 identifies that we fail to purge state of local
variables, based on behavior seen in PR analyzer/104954 when attempting
to profile slow performance of -fanalyzer on a particular file in the
Linux kernel, where that testcase has many temporary "boxed" values of
structs containing ints, which are never cleaned up, leading to bloat
of the program_state instances (specifically, of the store objects).

This patch generalizes the state purging from just being on SSA names
to also work on local variables.  Doing so requires that we detect where
addresses to a local variable (or within them) are taken; we assume that
once a pointer has been taken, it's not longer safe to purge the value
of that decl at any successor point within the function.

Doing so speeds up the PR analyzer/104954 Linux kernel analyzer testcase
from taking 254 seconds to "just" 186 seconds (and I have a followup
patch in development that seems to further reduce this to 37 seconds).

The patch may also help with scaling up taint-detection so that it can
eventually be turned on by default, but we're not quite there (this
is PR analyzer/103533).

gcc/analyzer/ChangeLog:
PR analyzer/104943
PR analyzer/104954
PR analyzer/103533
* analyzer.h (class state_purge_per_decl): New forward decl.
* engine.cc (impl_run_checkers): Pass region_model_manager to
state_purge_map ctor.
* program-point.cc (function_point::final_stmt_p): New.
(function_point::get_next): New.
* program-point.h (function_point::final_stmt_p): New decl.
(function_point::get_next): New decl.
* program-state.cc (program_state::prune_for_point): Generalize to
purge local decls as well as SSA names.
(program_state::can_purge_base_region_p): New.
* program-state.h (program_state::can_purge_base_region_p): New
decl.
* region-model.cc (struct append_ssa_names_cb_data): Rename to...
(struct append_regions_cb_data): ...this.
(region_model::get_ssa_name_regions_for_current_frame): Rename
to...
(region_model::get_regions_for_current_frame): ...this, updating
for other renamings.
(region_model::append_ssa_names_cb): Rename to...
(region_model::append_regions_cb): ...this, and drop the requirement
that the subregion be a SSA name.
* region-model.h (struct append_ssa_names_cb_data): Rename decl
to...
(struct append_regions_cb_data): ...this.
(region_model::get_ssa_name_regions_for_current_frame): Rename
decl to...
(region_model::get_regions_for_current_frame): ...this.
(region_model::append_ssa_names_cb): Rename decl to...
(region_model::append_regions_cb): ...this.
* state-purge.cc: Include "tristate.h", "selftest.h",
"analyzer/store.h", "analyzer/region-model.h", and
"gimple-walk.h".
(get_candidate_for_purging): New.
(class gimple_op_visitor): New.
(my_load_cb): New.
(my_store_cb): New.
(my_addr_cb): New.
(state_purge_map::state_purge_map): Add "mgr" param.  Update for
renamings.  Find uses of local variables.
(state_purge_map::~state_purge_map): Update for renaming of m_map
to m_ssa_map.  Clean up m_decl_map.
(state_purge_map::get_or_create_data_for_decl): New.
(state_purge_per_ssa_name::state_purge_per_ssa_name): Update for
inheriting from state_purge_per_tree.
(state_purge_per_ssa_name::add_to_worklist): Likewise.
(state_purge_per_decl::state_purge_per_decl): New.
(state_purge_per_decl::add_needed_at): New.
(state_purge_per_decl::add_pointed_to_at): New.
(state_purge_per_decl::process_worklists): New.
(state_purge_per_decl::add_to_worklist): New.
(same_binding_p): New.
(fully_overwrites_p): New.
(state_purge_per_decl::process_point_backwards): New.
(state_purge_per_decl::process_point_forwards): New.
(state_purge_per_decl::needed_at_point_p): New.
(state_purge_annotator::print_needed): Generalize to print local
decls as well as SSA names.
* state-purge.h (class state_purge_map): Update leading comment.
(state_purge_map::map_t): Rename to...
(state_purge_map::ssa_map_t): ...this.
(state_purge_map::iterator): Rename to...
(state_purge_map::ssa_iterator): ...this.
(state_purge_map::decl_map_t): New typedef.
(state_purge_map::decl_iterator): New typedef.
(state_purge_map::state_purge_map): Add "mgr" param.
(state_purge_map::get_data_for_ssa_name): Update for renaming.
(state_purge_map::get_any_data_for_decl): New.
(state_purge_map::get_or_create_data_for_decl): New decl.
(state_purge_map::begin): Rename to...
(state_purge_map::begin_ssas): ...this.
(state_purge_map::end): Rename to...
(state_purge_map::end_ssa): ...this.
(state_purge_map::begin_decls): New.
(state_purge_map::end_decls): New.
(state_purge_map::m_map): Rename to...
(state_purge_map::m_ssa_map): ...this.
(state_purge_map::m_decl_map): New field.
(class state_purge_per_tree): New class.
(class state_purge_per_ssa_name): Inherit from state_purge_per_tree.
(state_purge_per_ssa_name::get_function): Move to base class.
(state_purge_per_ssa_name::point_set_t): Likewise.
(state_purge_per_ssa_name::m_fun): Likewise.
(class state_purge_per_decl): New.

gcc/testsuite/ChangeLog:
PR analyzer/104943
PR analyzer/104954
PR analyzer/103533
* gcc.dg/analyzer/torture/boxed-ptr-1.c: Update expected number
of exploded nodes to reflect improvements in state purging.

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

analyzer: add tests of boxed values [PR104943]

This patch adds various regression tests as preparatory work for
purging irrelevant local decls from state (PR analyzer/104943)

gcc/testsuite/ChangeLog:
PR analyzer/104943
* gcc.dg/analyzer/boxed-malloc-1-29.c: New test.
* gcc.dg/analyzer/boxed-malloc-1.c: New test.
* gcc.dg/analyzer/taint-alloc-5.c: New test.
* gcc.dg/analyzer/torture/boxed-int-1.c: New test.
* gcc.dg/analyzer/torture/boxed-ptr-1.c: New test.

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

[PR104961] LRA: split hard reg for reload pseudo with clobber.

Splitting hard register live range did not work for subreg of a
multi-reg reload pseudo.  Reload insns for such pseudo contain clobber
of the pseudo and splitting did not take this into account.  The patch
fixes it.

gcc/ChangeLog:

PR rtl-optimization/104961
* lra-assigns.cc (find_reload_regno_insns): Process reload pseudo clobber.

gcc/testsuite/ChangeLog:

PR rtl-optimization/104961
* gcc.target/i386/pr104961.c: New.

tree: Add comment.

gcc/ChangeLog:

* tree.h (IDENTIFIER_LENGTH): Add comment.

c++: using lookup within class defn [PR104476]

The problem in both PR92918 and PR104476 is overloading of base member
functions brought in by 'using' with direct member functions during parsing
of the class body.  To this point they've had a troublesome coexistence
which was resolved by set_class_bindings when the class is complete, but we
also need to handle lookup within the class body, such as in a trailing
return type.

The problem was that push_class_level_binding would either clobber the
using-decl with the direct members or vice-versa.  In older versions of GCC
we only pushed dependent usings, and preferring the dependent using made
sense, as it expresses a type-dependent overload set that we can't do
anything useful with.  But when we started keeping non-dependent usings
around, push_class_level_binding in particular wasn't adjusted accordingly.

This patch makes that adjustment, and pushes the functions imported by a
non-dependent using immediately from finish_member_declaration.  This made
diagnosing redundant using-decls a bit awkward, since we no longer push the
using-decl itself; I handle that by noticing when we try to add the same
function again and searching TYPE_FIELDS for the previous using-decl.

PR c++/92918
PR c++/104476

gcc/cp/ChangeLog:

* class.cc (add_method): Avoid adding the same used function twice.
(handle_using_decl): Don't add_method.
(finish_struct): Don't using op= if we have one already.
(maybe_push_used_methods): New.
* semantics.cc (finish_member_declaration): Call it.
* name-lookup.cc (diagnose_name_conflict): No longer static.
(push_class_level_binding): Revert 92918 patch, limit
to dependent using.
* cp-tree.h: Adjust.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/pr85070.C: Remove expected error.
* g++.dg/lookup/using66a.C: New test.
* g++.dg/lookup/using67.C: New test.

Allow (void *) 0xdeadbeef accesses without warnings [PR99578]

Starting with GCC11 we keep emitting false positive -Warray-bounds or
-Wstringop-overflow etc. warnings on widely used *(type *)0x12345000
style accesses (or memory/string routines to such pointers).
This is a standard programming style supported by all C/C++ compilers
I've ever tried, used mostly in kernel or DSP programming, but sometimes
also together with mmap MAP_FIXED when certain things, often I/O registers
but could be anything else too are known to be present at fixed
addresses.

Such INTEGER_CST addresses can appear in code either because a user
used it like that (in which case it is fine) or because somebody used
pointer arithmetics (including &((struct whatever *)NULL)->field) on
a NULL pointer.  The middle-end warning code wrongly assumes that the
latter case is what is very likely, while the former is unlikely and
users should change their code.

The following patch adds a min-pagesize param defaulting to 4KB,
and treats INTEGER_CST addresses smaller than that as assumed results
of pointer arithmetics from NULL while addresses equal or larger than
that as expected user constant addresses.  For GCC 13 we can
represent results from pointer arithmetics on NULL using
&MEM[(void*)0 + offset] instead of (void*)offset INTEGER_CSTs.

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

PR middle-end/99578
PR middle-end/100680
PR tree-optimization/100834
* params.opt (--param=min-pagesize=): New parameter.
* pointer-query.cc
(compute_objsize_r) <case ARRAY_REF>: Formatting fix.
(compute_objsize_r) <case INTEGER_CST>: Use maximum object size instead
of zero for pointer constants equal or larger than min-pagesize.

* gcc.dg/tree-ssa/pr99578-1.c: New test.
* gcc.dg/pr99578-1.c: New test.
* gcc.dg/pr99578-2.c: New test.
* gcc.dg/pr99578-3.c: New test.
* gcc.dg/pr100680.c: New test.
* gcc.dg/pr100834.c: New test.

c++: Fix up constexpr evaluation of new with zero sized types [PR104568]

The new expression constant expression evaluation right now tries to
deduce how many elts the array it uses for the heap or heap [] vars
should have (or how many elts should its trailing array have if it has
cookie at the start).  As new is lowered at that point to
(some_type *) ::operator new (size)
or so, it computes it by subtracting cookie size if any from size, then
divides the result by sizeof (some_type).
This works fine for most types, except when sizeof (some_type) is 0,
then we divide by zero; size is then equal to cookie_size (or if there
is no cookie, to 0).
The following patch special cases those cases so that we don't divide
by zero and also recover the original outer_nelts from the expression
by forcing the size not to be folded in that case but be explicit
0 * outer_nelts or cookie_size + 0 * outer_nelts.

Note, we have further issues, we accept-invalid various cases, for both
zero sized elt_type and even non-zero sized elts, we aren't able to
diagnose out of bounds POINTER_PLUS_EXPR like:
constexpr bool
foo ()
{
  auto p = new int[2];
  auto q1 = &p[0];
  auto q2 = &p[1];
  auto q3 = &p[2];
  auto q4 = &p[3];
  delete[] p;
  return true;
}
constexpr bool a = foo ();
That doesn't look like a regression so I think we should resolve that for
GCC 13, but there are 2 problems.  Figure out why
cxx_fold_pointer_plus_expression doesn't deal with the &heap []
etc. cases, and for the zero sized arrays, I think we really need to preserve
whether user wrote an array ref or pointer addition, because in the
&p[3] case if sizeof(p[0]) == 0 we know that if it has 2 elements it is
out of bounds, while if we see p p+ 0 the information if it was
p + 2 or p + 3 in the source is lost.
clang++ seems to handle it fine even in the zero sized cases or with
new expressions.

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

PR c++/104568
* init.cc (build_new_constexpr_heap_type): Remove FULL_SIZE
argument and its handling, instead add ITYPE2 argument.  Only
support COOKIE_SIZE != NULL.
(build_new_1): If size is 0, change it to 0 * outer_nelts if
outer_nelts is non-NULL.  Pass type rather than elt_type to
maybe_wrap_new_for_constexpr.
* constexpr.cc (build_new_constexpr_heap_type): New function.
(cxx_eval_constant_expression) <case CONVERT_EXPR>:
If elt_size is zero sized type, try to recover outer_nelts from
the size argument to operator new/new[] and pass that as
arg_size to build_new_constexpr_heap_type.  Pass ctx,
non_constant_p and overflow_p to that call too.

* g++.dg/cpp2a/constexpr-new22.C: New test.

testsuite: Add missing <vector> header to test

gcc/testsuite/ChangeLog:

* g++.dg/torture/pr104601.C: Include <vector>.

c++: alias template and empty parameter packs [PR104008]

Zero-length pack expansions are treated as if no list were provided
at all, that is, with

  template<typename...> struct S { };
  template<typename T, typename... Ts>
  void g() {
    S<std::is_same<T, Ts>...>;
  }

g<int> will result in S<>.  In the following test we have something
similar:

  template <typename T, typename... Ts>
  using IsOneOf = disjunction<is_same<T, Ts>...>;

and then we have "IsOneOf<OtherHolders>..." where OtherHolders is an
empty pack.  Since r11-7931, we strip_typedefs in TYPE_PACK_EXPANSION.
In this test that results in "IsOneOf<OtherHolders>" being turned into
"disjunction<>".  So the whole expansion is now "disjunction<>...".  But
then we error in make_pack_expansion because find_parameter_packs_r won't
find the pack OtherHolders.

We strip the alias template because dependent_alias_template_spec_p says
it's not dependent.  It it not dependent because this alias is not
TEMPLATE_DECL_COMPLEX_ALIAS_P.  My understanding is that currently we
consider an alias complex if it

1) expands a pack from the enclosing class, as in

    template<template<typename... U> typename... TT>
    struct S {
      template<typename... Args>
      using X = P<TT<Args...>...>;
    };

   where the alias expands TT; or

2) the expansion does *not* name all the template parameters, as in

    template<typename...> struct R;
    template<typename T, typename... Ts>
    using U = R<X<Ts>...>;

   where T is not named in the expansion.

But IsOneOf is neither.  And it can't know how it's going to be used.
Therefore I think we cannot make it complex (and in turn dependent) to fix
this bug.

After much gnashing of teeth, I think we simply want to avoid stripping
the alias if the new pattern doesn't have any parameter packs to expand.

PR c++/104008

gcc/cp/ChangeLog:

* tree.cc (strip_typedefs): Don't strip an alias template when
doing so would result in losing a parameter pack.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/variadic-alias3.C: New test.
* g++.dg/cpp0x/variadic-alias4.C: New test.

Fortran/OpenMP: Fix privatization of associated names

gfc_omp_predetermined_sharing cases the associate-name pointer variable
to be OMP_CLAUSE_DEFAULT_FIRSTPRIVATE, which is fine. However, the associated
selector is shared. Thus, the target of associate-name pointer should not get
copied. (It was before but because of gfc_omp_privatize_by_reference returning
false, the selector was not only wrongly copied but this was also not done
properly.)

gcc/fortran/ChangeLog:

PR fortran/103039
* trans-openmp.cc (gfc_omp_clause_copy_ctor, gfc_omp_clause_dtor):
Only privatize pointer for associate names.

libgomp/ChangeLog:

PR fortran/103039
* testsuite/libgomp.fortran/associate4.f90: New test.

libstdc++: Simplify constraints for std::any construction [PR104242]

Partially revert r12-4190-g6da36b7d0e43b6f9281c65c19a025d4888a25b2d
because using __and_<..., is_copy_constructible<T>> when T is incomplete
results in an error about deriving from is_copy_constructible<T> when
that is incomplete. I don't know how to fix that, so this simply
restores the previous constraint which worked in this case (even though
I think it's technically undefined to use is_copy_constructible<T> with
incomplete T). This doesn't restore exactly what we had before, but uses
the is_copy_constructible_v and __is_in_place_type_v variable templates
instead of the ::value member.

libstdc++-v3/ChangeLog:

PR libstdc++/104242
* include/std/any (any(T&&)): Revert change to constraints.
* testsuite/20_util/any/cons/104242.cc: New test.

testsuite, modules, Darwin: Adjust expected output for older OS versions.

Darwin versions <= 10 (macOS 10.6) emit different diagnostics for the failure
case being tested by bad-mapper-1.C.  Adjust the dg- expressions to reflect this.

Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>
gcc/testsuite/ChangeLog:

* g++.dg/modules/bad-mapper-1.C: Make dg- expressions that match the
diagnostics output by earlier Darwin too.

Fix "[openmp] Set location for taskloop stmts"

I accidentally committed an outdated version of patch "[openmp] Set location
for taskloop stmts".

Fix this by adding the missing changes.

gcc/ChangeLog:

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

* gimplify.cc (gimplify_omp_for): Set location using 'input_location'.
Set gfor location only when dealing with a OMP_TASKLOOP.

c++tools: Work around a BSD bug in getaddrinfo().

Some versions of the BSD getaddrinfo() call do not work with the specific
input of "0" for the servname entry (a segv results).  Since we are making
the call with a dummy port number, the value is actually no important, other
than it should be in range.  Work around the BSD bug by using "1" instead.

Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>
c++tools/ChangeLog:

* server.cc (accept_from): Use "1" as the dummy port number.

libcody: Do not use a dummy port number in getaddrinfo().

the getaddrinfo() requires either a non-null name for the server or
a port service / number.  In the code that opens a connection we have
been calling this with a dummy port number of "0".  Unfortunately this
triggers a bug in some BSD versions and OSes importing that code.

In this part of the code we do not really need a port number, since it
is not reasonable to open a connection to an unspecified host.

Setting hints info field to 0, and the servname parm to nullptr works
around the BSD bug in this case.

Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>
libcody/ChangeLog:

* netclient.cc (OpenInet6): Do not provide a dummy port number
in the getaddrinfo() call.