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.

[openmp] Set location for taskloop stmts

The test-case included in this patch contains:
...
  #pragma omp taskloop simd shared(a) lastprivate(myId)
...

This is translated to 3 taskloop statements in gimple, visible with
-fdump-tree-gimple:
...
  #pragma omp taskloop private(D.2124)
    #pragma omp taskloop shared(a) shared(myId) private(i.0) firstprivate(a_h)
      #pragma omp taskloop lastprivate(myId)
...

But when exposing the gimple statement locations using
-fdump-tree-gimple-lineno, we find that only the first one has location
information.

Fix this by adding the missing location information.

Tested gomp.exp on x86_64.

Tested libgomp testsuite on x86_64 with nvptx accelerator.

gcc/ChangeLog:

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

* gimplify.cc (gimplify_omp_for): Set taskloop location.

gcc/testsuite/ChangeLog:

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

* c-c++-common/gomp/pr104968.c: New test.

[openmp] Fix SIMT reduction using TRUTH_{AND,OR}IF_EXPR

Consider test-case pr104952-1.c, included in this commit, containing:
...
  #pragma omp target map(tofrom:result) map(to:arr)
  #pragma omp simd reduction(||: result)
...

When run on x86_64 with nvptx accelerator, the test-case either aborts or
hangs.

The reduction clause is translated by the SIMT code (active for nvptx) as a
butterfly reduction loop with this butterfly shuffle / update pair:
...
  D.2163 = D.2163 || .GOMP_SIMT_XCHG_BFLY (D.2163, D.2164)
...
in the loop body.

The problem is that the butterfly shuffle is possibly not executed, while it
needs to be executed unconditionally.

Fix this by translating instead as:
...
  D.tmp_bfly = .GOMP_SIMT_XCHG_BFLY (D.2163, D.2164)
  D.2163 = D.2163 || D.tmp_bfly
...

Tested on x86_64-linux with nvptx accelerator.

gcc/ChangeLog:

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

PR target/104952
* omp-low.cc (lower_rec_input_clauses): Make sure GOMP_SIMT_XCHG_BFLY
is executed unconditionally.

libgomp/ChangeLog:

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

PR target/104952
* testsuite/libgomp.c/pr104952-1.c: New test.
* testsuite/libgomp.c/pr104952-2.c: New test.

Fortran/OpenMP: Improve associate-name diagnostic [PR103039]

gcc/fortran/ChangeLog:

PR fortran/103039
* openmp.cc (resolve_omp_clauses): Improve associate-name diagnostic
for select type/rank.

gcc/testsuite/ChangeLog:

PR fortran/103039
* gfortran.dg/gomp/associate1.f90: Update dg-error.
* gfortran.dg/gomp/associate2.f90: New test.

Refine HImode movement for "v" to "v".

Set attr from HImode to HFmode which uses vmovsh instead of vmovw for
movment between sse registers.

gcc/ChangeLog:

PR target/104974
* config/i386/i386.md (*movhi_internal): Set attr type from HI
to HF for alternative 12 under TARGET_AVX512FP16.

gcc/testsuite/ChangeLog:

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

libstdc++: Reduce header dependencies from PSTL headers [PR92546]

This avoids including the whole of <functional> in <algorithm>, as the
<pstl/glue_algorithm_defs.h> header only actually needs std::pair.

This also avoids including <iterator> in <pstl/utils.h>, which only
needs <type_traits>, std::bad_alloc, and std::terminate (which can be
repalced with std::__terminate). This matters less, because
<pstl/utils.h> is only included by the <pstl/*_impl.h> headers and they
all use <iterator> anyway, and are only included by <execution>.

libstdc++-v3/ChangeLog:

PR libstdc++/92546
* include/pstl/glue_algorithm_defs.h: Replace <functional> with
<bits/stl_pair.h>.
* include/pstl/utils.h: Replace <iterator> with <type_traits>.
(__pstl::__internal::__except_handler): Use std::__terminate
instead of std::terminate.
* src/c++17/fs_path.cc: Include <array>.
* testsuite/25_algorithms/adjacent_find/constexpr.cc: Include
<functional>.
* testsuite/25_algorithms/binary_search/constexpr.cc: Likewise.
* testsuite/25_algorithms/clamp/constrained.cc: Likewise.
* testsuite/25_algorithms/equal/constrained.cc: Likewise.
* testsuite/25_algorithms/for_each/constrained.cc: Likewise.
* testsuite/25_algorithms/includes/constrained.cc: Likewise.
* testsuite/25_algorithms/is_heap/constexpr.cc: Likewise.
* testsuite/25_algorithms/is_heap_until/constexpr.cc: Likewise.
* testsuite/25_algorithms/is_permutation/constrained.cc: Include
<iterator>.
* testsuite/25_algorithms/is_sorted/constexpr.cc: Include
<functional>.
* testsuite/25_algorithms/is_sorted_until/constexpr.cc:
Likewise.
* testsuite/25_algorithms/lexicographical_compare/constexpr.cc:
Likewise.
* testsuite/25_algorithms/lexicographical_compare/constrained.cc:
Likewise.
* testsuite/25_algorithms/lexicographical_compare_three_way/1.cc:
Include <array>.
* testsuite/25_algorithms/lower_bound/constexpr.cc: Include
<functional>.
* testsuite/25_algorithms/max/constrained.cc: Likewise.
* testsuite/25_algorithms/max_element/constrained.cc: Likewise.
* testsuite/25_algorithms/min/constrained.cc: Likewise.
* testsuite/25_algorithms/min_element/constrained.cc: Likewise.
* testsuite/25_algorithms/minmax_element/constrained.cc:
Likewise.
* testsuite/25_algorithms/mismatch/constexpr.cc: Likewise.
* testsuite/25_algorithms/move/93872.cc: Likewise.
* testsuite/25_algorithms/move_backward/93872.cc: Include
<iterator>.
* testsuite/25_algorithms/nth_element/constexpr.cc: Include
<functional>.
* testsuite/25_algorithms/partial_sort/constexpr.cc: Likewise.
* testsuite/25_algorithms/partial_sort_copy/constexpr.cc:
Likewise.
* testsuite/25_algorithms/search/constexpr.cc: Likewise.
* testsuite/25_algorithms/search_n/constrained.cc: Likewise.
* testsuite/25_algorithms/set_difference/constexpr.cc: Likewise.
* testsuite/25_algorithms/set_difference/constrained.cc:
Likewise.
* testsuite/25_algorithms/set_intersection/constexpr.cc:
Likewise.
* testsuite/25_algorithms/set_intersection/constrained.cc:
Likewise.
* testsuite/25_algorithms/set_symmetric_difference/constexpr.cc:
Likewise.
* testsuite/25_algorithms/set_union/constexpr.cc: Likewise.
* testsuite/25_algorithms/set_union/constrained.cc: Likewise.
* testsuite/25_algorithms/sort/constexpr.cc: Likewise.
* testsuite/25_algorithms/sort_heap/constexpr.cc: Likewise.
* testsuite/25_algorithms/transform/constrained.cc: Likewise.
* testsuite/25_algorithms/unique/constexpr.cc: Likewise.
* testsuite/25_algorithms/unique/constrained.cc: Likewise.
* testsuite/25_algorithms/unique_copy/constexpr.cc: Likewise.
* testsuite/25_algorithms/upper_bound/constexpr.cc: Likewise.
* testsuite/std/ranges/adaptors/elements.cc: Include <vector>.
* testsuite/std/ranges/adaptors/lazy_split.cc: Likewise.
* testsuite/std/ranges/adaptors/split.cc: Likewise.

openmp: Fix up gomp_affinity_init_numa_domains

On Thu, Nov 11, 2021 at 02:14:05PM +0100, Thomas Schwinge wrote:
> There appears to be yet another issue: there still are quite a number of
> 'FAIL: libgomp.c/places-10.c execution test' reports on
> <gcc-testresults@gcc.gnu.org>.  Also in my testing testing, on a system
> where '/sys/devices/system/node/online' contains '0-1', I get a FAIL:
>
>     [...]
>     OPENMP DISPLAY ENVIRONMENT BEGIN
>       _OPENMP = '201511'
>       OMP_DYNAMIC = 'FALSE'
>       OMP_NESTED = 'FALSE'
>       OMP_NUM_THREADS = '8'
>       OMP_SCHEDULE = 'DYNAMIC'
>       OMP_PROC_BIND = 'TRUE'
>       OMP_PLACES = '{0,2,4,6,8,10,12,14,16,18,20,22,24,26,28,30},{FAIL: libgomp.c/places-10.c execution test

I've finally managed to debug this (by dumping used /sys/ files from
an affected system in Fedora build system, replacing /sys/ with /tmp/
in gcc sources and populating there those files), I think following patch
ought to fix it.

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

* config/linux/affinity.c (gomp_affinity_init_numa_domains): Move seen
variable next to pl variable.

x86: Correct march=sapphirerapids to base on icelake server

march=sapphirerapids should be based on icelake server not cooperlake.

gcc/ChangeLog:

PR target/104963
* config/i386/i386.h (PTA_SAPPHIRERAPIDS): change it to base on ICX.
* doc/invoke.texi: Update documents for Intel sapphirerapids.

gcc/testsuite/ChangeLog:

PR target/104963
* gcc.target/i386/pr104963.c: New test case.

Daily bump.

analyzer: fixes to -fdump-analyzer-state-purge

gcc/analyzer/ChangeLog:
* state-purge.cc (state_purge_annotator::add_node_annotations):
Avoid duplicate before-supernode annotations when returning from
an interprocedural call.  Show after-supernode annotations.

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

analyzer: fix program_point::get_next for PK_BEFORE_STMT

gcc/analyzer/ChangeLog:
* program-point.cc (program_point::get_next): Fix missing
increment of index.

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

PR 90356: Use xor to load const_double 0.0 on SSE (always)

Implementations of the x87 floating point instruction set have always
had some pretty strange characteristics.  For example on the original
Intel Pentium the FLDPI instruction (to load 3.14159... into a register)
took 5 cycles, and the FLDZ instruction (to load 0.0) took 2 cycles,
when a regular FLD (load from memory) took just 1 cycle!?  Given that
back then memory latencies were much lower (relatively) than they are
today, these instructions were all but useless except when optimizing
for size (impressively FLDZ/FLDPI require only two bytes).

Such was the world back in 2006 when Uros Bizjak first added support for
fldz https://gcc.gnu.org/pipermail/gcc-patches/2006-November/202589.html
and then shortly after sensibly disabled them for !optimize_size with
https://gcc.gnu.org/pipermail/gcc-patches/2006-November/204405.html

Alas this vestigial logic still persists in the compiler today,
so for example on x86_64 for the following function:

double foo(double x) { return x + 0.0; }

generates with -O2

foo:    addsd   .LC0(%rip), %xmm0
        ret
.LC0:   .long   0
        .long   0

preferring to read the constant 0.0 from memory [the constant pool],
except when optimizing for size.  With -Os we get:

foo:    xorps   %xmm1, %xmm1
        addsd   %xmm1, %xmm0
        ret

Which is not only smaller (the two instructions require seven bytes vs.
eight for the original addsd from mem, even without considering the
constant pool) but is also faster on modern hardware.  The latter code
sequence is generated by both clang and msvc with -O2.  Indeed Agner
Fogg documents the set of floating point/SSE constants that it's
cheaper to materialize than to load from memory.

This patch shuffles the conditions on the i386 backend's *movtf_internal,
*movdf_internal and *movsf_internal define_insns to untangle the newer
TARGET_SSE_MATH clauses from the historical standard_80387_constant_p
conditions.  Amongst the benefits of this are that it improves the code
generated for PR tree-optimization/90356 and resolves PR target/86722.

2022-03-17  Roger Sayle  <roger@nextmovesoftware.com>

gcc/ChangeLog
PR target/86722
PR tree-optimization/90356
* config/i386/i386.md (*movtf_internal): Don't guard
standard_sse_constant_p clause by optimize_function_for_size_p.
(*movdf_internal): Likewise.
(*movsf_internal): Likewise.

gcc/testsuite/ChangeLog
PR target/86722
PR tree-optimization/90356
* gcc.target/i386/pr86722.c: New test case.
* gcc.target/i386/pr90356.c: New test case.

Always use dominators in the cache when available.

This patch adjusts range_from_dom to follow the dominator tree through the
cache until value is found, then apply any outgoing ranges encountered
along the way.  This reduces the amount of cache storage required.

PR tree-optimization/102943
* gimple-range-cache.cc (ranger_cache::range_from_dom): Find range via
dominators and apply intermediary outgoing edge ranges.

libstdc++: Avoid including <algorithm> in <filesystem> [PR92546]

This only affects Windows, but reduces the preprocessed size of
<filesystem> significantly.

libstdc++-v3/ChangeLog:

PR libstdc++/92546
* include/bits/fs_path.h (path::make_preferred): Use
handwritten loop instead of std::replace.

libstdc++: Rewrite __moneypunct_cache::_M_cache [PR104966]

GCC thinks the following can lead to a buffer overflow when __ns.size()
equals zero:

  const basic_string<_CharT>& __ns = __mp.negative_sign();
  _M_negative_sign_size = __ns.size();
  __negative_sign = new _CharT[_M_negative_sign_size];
  __ns.copy(__negative_sign, _M_negative_sign_size);

This happens because operator new might be replaced with something that
writes to this->_M_negative_sign_size and so the basic_string::copy call
could use a non-zero size to write to a zero-length buffer.

The solution suggested by Richi is to cache the size in a local variable
so that the compiler knows it won't be changed between the allocation
and the copy.

This commit goes further and rewrites the whole function to use RAII and
delay all modifications of *this until after all allocations have
succeeded. The RAII helper type caches the size and copies the string
and owns the memory until told to release it.

libstdc++-v3/ChangeLog:

PR middle-end/104966
* include/bits/locale_facets_nonio.tcc
(__moneypunct_cache::_M_cache): Replace try-catch with RAII and
make all string copies before any stores to *this.

libatomic: Improve 16-byte atomics on Intel AVX [PR104688]

As mentioned in the PR, the latest Intel SDM has added:
"Processors that enumerate support for Intel® AVX (by setting the feature flag CPUID.01H:ECX.AVX[bit 28])
guarantee that the 16-byte memory operations performed by the following instructions will always be
carried out atomically:
• MOVAPD, MOVAPS, and MOVDQA.
• VMOVAPD, VMOVAPS, and VMOVDQA when encoded with VEX.128.
• VMOVAPD, VMOVAPS, VMOVDQA32, and VMOVDQA64 when encoded with EVEX.128 and k0 (masking disabled).
(Note that these instructions require the linear addresses of their memory operands to be 16-byte
aligned.)"

The following patch deals with it just on the libatomic library side so far,
currently (since ~ 2017) we emit all the __atomic_* 16-byte builtins as
library calls since and this is something that we can hopefully backport.

The patch simply introduces yet another ifunc variant that takes priority
over the pure CMPXCHG16B one, one that checks AVX and CMPXCHG16B bits and
on non-Intel clears the AVX bit during detection for now (if AMD comes
with the same guarantee, we could revert the config/x86/init.c hunk),
which implements 16-byte atomic load as vmovdqa and 16-byte atomic store
as vmovdqa followed by mfence.

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

PR target/104688
* Makefile.am (IFUNC_OPTIONS): Change on x86_64 to -mcx16 -mcx16.
(libatomic_la_LIBADD): Add $(addsuffix _16_2_.lo,$(SIZEOBJS)) for
x86_64.
* Makefile.in: Regenerated.
* config/x86/host-config.h (IFUNC_COND_1): For x86_64 define to
both AVX and CMPXCHG16B bits.
(IFUNC_COND_2): Define.
(IFUNC_NCOND): For x86_64 define to 2 * (N == 16).
(MAYBE_HAVE_ATOMIC_CAS_16, MAYBE_HAVE_ATOMIC_EXCHANGE_16,
MAYBE_HAVE_ATOMIC_LDST_16): Define to IFUNC_COND_2 rather than
IFUNC_COND_1.
(HAVE_ATOMIC_CAS_16): Redefine to 1 whenever IFUNC_ALT != 0.
(HAVE_ATOMIC_LDST_16): Redefine to 1 whenever IFUNC_ALT == 1.
(atomic_compare_exchange_n): Define whenever IFUNC_ALT != 0
on x86_64 for N == 16.
(__atomic_load_n, __atomic_store_n): Redefine whenever IFUNC_ALT == 1
on x86_64 for N == 16.
(atomic_load_n, atomic_store_n): New functions.
* config/x86/init.c (__libat_feat1_init): On x86_64 clear bit_AVX
if CPU vendor is not Intel.

libstdc++: Fix comment in testsuite utility

libstdc++-v3/ChangeLog:

* testsuite/util/testsuite_character.h: Fix comment.

tree-optimization/104960 - unsplit edges after late sinking

Something went wrong when testing the earlier patch to move the
late sinking to before the late phiopt for PR102008.  The following
makes sure to unsplit edges after the late sinking since the split
edges confuse the following phiopt leading to missed optimizations.

I've went for a new pass parameter for this to avoid changing the
CFG after the early sinking pass at this point.

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

PR tree-optimization/104960
* passes.def: Add pass parameter to pass_sink_code, mark
last one to unsplit edges.
* tree-ssa-sink.cc (pass_sink_code::set_pass_param): New.
(pass_sink_code::execute): Always execute TODO_cleanup_cfg
when we need to unsplit edges.

* gcc.dg/gimplefe-37.c: Adjust to allow either the true
or false edge to have a forwarder.

gimplify: Emit clobbers for TARGET_EXPR_SLOT vars later [PR103984]

As mentioned in the PR, we emit a bogus uninitialized warning but
easily could emit wrong-code for it or similar testcases too.
The bug is that we emit clobber for a TARGET_EXPR_SLOT too early:
          D.2499.e = B::qux (&h); [return slot optimization]
          D.2516 = 1;
          try
            {
              B::B (&D.2498, &h);
              try
                {
                  _2 = baz (&D.2498);
                  D.2499.f = _2;
                  D.2516 = 0;
                  try
                    {
                      try
                        {
                          bar (&D.2499);
                        }
                      finally
                        {
                          C::~C (&D.2499);
                        }
                    }
                  finally
                    {
                      D.2499 = {CLOBBER(eol)};
                    }
                }
              finally
                {
                  D.2498 = {CLOBBER(eol)};
                }
            }
          catch
            {
              if (D.2516 != 0) goto <D.2517>; else goto <D.2518>;
              <D.2517>:
              A::~A (&D.2499.e);
              goto <D.2519>;
              <D.2518>:
              <D.2519>:
            }
The CLOBBER for D.2499 is essentially only emitted on the non-exceptional
path, if B::B or baz throws, then there is no CLOBBER for it but there
is a conditional destructor A::~A (&D.2499.e).  Now, ehcleanup1
sink_clobbers optimization assumes that clobbers in the EH cases are
emitted after last use and so sinks the D.2499 = {CLOBBER(eol)}; later,
so we then have
  # _3 = PHI <1(3), 0(9)>
<L2>:
  D.2499 ={v} {CLOBBER(eol)};
  D.2498 ={v} {CLOBBER(eol)};
  if (_3 != 0)
    goto <bb 11>; [INV]
  else
    goto <bb 15>; [INV]

  <bb 11> :
  _35 = D.2499.a;
  if (&D.2499.b != _35)
where that _35 = D.2499.a comes from inline expansion of the A::~A dtor,
and that is a load from a clobbered memory.

Now, what the gimplifier sees in this case is a CLEANUP_POINT_EXPR with
somewhere inside of it a TARGET_EXPR for D.2499 (with the C::~C (&D.2499)
cleanup) which in its TARGET_EXPR_INITIAL has another TARGET_EXPR for
D.2516 bool flag which has CLEANUP_EH_ONLY which performs that conditional
A::~A (&D.2499.e) call.
The following patch ensures that CLOBBERs (and asan poisoning) are emitted
after even those gimple_push_cleanup pushed cleanups from within the
TARGET_EXPR_INITIAL gimplification (i.e. the last point where the slot could
be in theory used).  In my first version of the patch I've done it by just
moving the
      /* Add a clobber for the temporary going out of scope, like
         gimplify_bind_expr.  */
      if (gimplify_ctxp->in_cleanup_point_expr
          && needs_to_live_in_memory (temp))
        {
...
        }
block earlier in gimplify_target_expr, but that regressed a couple of tests
where temp is marked TREE_ADDRESSABLE only during (well, very early during
that) the gimplification of TARGET_EXPR_INITIAL, so we didn't emit e.g. on
pr80032.C or stack2.C tests any clobbers for the slots and thus stack slot
reuse wasn't performed.
So that we don't regress those tests, this patch gimplifies
TARGET_EXPR_INITIAL as before, but doesn't emit it directly into pre_p,
emits it into a temporary sequence.  Then emits the CLOBBER cleanup
into pre_p, then asan poisoning if needed, then appends the
TARGET_EXPR_INITIAL temporary sequence and finally adds TARGET_EXPR_CLEANUP
gimple_push_cleanup.  The earlier a GIMPLE_WCE appears in the sequence, the
outer try/finally or try/catch it is.
So, with this patch the part of the testcase in gimple dump cited above
looks instead like:
          try
            {
              D.2499.e = B::qux (&h); [return slot optimization]
              D.2516 = 1;
              try
                {
                  try
                    {
                      B::B (&D.2498, &h);
                      _2 = baz (&D.2498);
                      D.2499.f = _2;
                      D.2516 = 0;
                      try
                        {
                          bar (&D.2499);
                        }
                      finally
                        {
                          C::~C (&D.2499);
                        }
                    }
                  finally
                    {
                      D.2498 = {CLOBBER(eol)};
                    }
                }
              catch
                {
                  if (D.2516 != 0) goto <D.2517>; else goto <D.2518>;
                  <D.2517>:
                  A::~A (&D.2499.e);
                  goto <D.2519>;
                  <D.2518>:
                  <D.2519>:
                }
            }
          finally
            {
              D.2499 = {CLOBBER(eol)};
            }

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

PR middle-end/103984
* gimplify.cc (gimplify_target_expr): Gimplify type sizes and
TARGET_EXPR_INITIAL into a temporary sequence, then push clobbers
and asan unpoisioning, then append the temporary sequence and
finally the TARGET_EXPR_CLEANUP clobbers.

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

Enhance further testcases to verify Openacc 'kernels' decomposition

gcc/testsuite/
* c-c++-common/goacc-gomp/nesting-1.c: Enhance.
* c-c++-common/goacc/kernels-loop-g.c: Likewise.
* c-c++-common/goacc/nesting-1.c: Likewise.
* gcc.dg/goacc/nested-function-1.c: Likewise.
* gfortran.dg/goacc/common-block-3.f90: Likewise.
* gfortran.dg/goacc/nested-function-1.f90: Likewise.
libgomp/
* testsuite/libgomp.oacc-c-c++-common/acc_prof-kernels-1.c:
Enhance.
* testsuite/libgomp.oacc-c-c++-common/kernels-loop-g.c: Likewise.
* testsuite/libgomp.oacc-fortran/if-1.f90: Likewise.