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