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.

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.

gcc/fortran/ChangeLog:

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

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.

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.

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.

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.

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.

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.

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.

	PR target/104902

gcc/ChangeLog:

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

	PR target/104903

gcc/ChangeLog:

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

      PR target/104904

gcc/ChangeLog:

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

	PR target/104898

gcc/ChangeLog:

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

	* sv.po: Update.

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 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 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.

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