Relax slightly the existing check for diagnosing a bare CTAD placeholder
as the return type of a function declarator to also handle the abstract
declarator case.
gcc/cp/ChangeLog:
* decl.cc (grokdeclarator): Diagnose a CTAD placeholder as
function return type even when !funcdecl_p.
gcc/testsuite/ChangeLog:
* g++.dg/other/pr88187.C: Adjust expected C++17 diagnostic.
This avoids ICEing when there is no LHS on the call by following
what foldings of other builtins do in , namely not folding.
2022-01-20 Richard Biener <rguenther@suse.de>
PR target/100784
* config/i386/i386.cc (ix86_gimple_fold_builtin): Check for
LHS before folding __builtin_ia32_shufpd and friends.
Clang doesn't support the __constinit extension that we use pre-C++20,
but it does have its own equivalent attribute that can be used instead.
This makes it a little easier to use Clang to build libstdc++ (which
isn't supported. but is sometimes attempted for esoteric targets).
libstdc++-v3/ChangeLog:
* src/c++11/cxx11-ios_failure.cc (__constinit): Define as
equivalent attribute for Clang.
* src/c++11/future.cc (__constinit): Likewise.
* src/c++11/system_error.cc (__constinit): Likewise.
* src/c++17/memory_resource.cc (__constinit): Likewise.
The MacOS linker warns about -L arguments that don't exist, which causes
all tests to fail for the defauly configuration (because libbacktrace
isn't built).
libstdc++-v3/ChangeLog:
* scripts/testsuite_flags.in: Only add src/filesystem/.libs and
src/libbacktrace/.libs to LDFLAGS if those directories exist.
Add a testcase for the erratum mitigation. To improve coverage
use -dp on the assembler output and match the pattern names (and where
needed the alternative number).
gcc/testsuite/ChangeLog:
* gcc.target/arm/crypto-vaese-erratum1.c: New test.
Some common cases where the AES erratum workaround are not required
are when there are 64- or 128-bit loads from memory, moving a 128-bit
value from core registers, and where a 128-bit constant is being
loaded from a literal pool. The loads may also be misaligned or
generated via a neon intrinsic function.
gcc/ChangeLog:
* config/arm/crypto.md (aes_op_protect): Allow moves from core
registers and from memory.
(aes_op_protect_misalign_load): New pattern.
(aes_op_protect_neon_vld1v16qi): New pattern.
AES operations are commonly chained and since the result of one AES
operation is never a 32-bit value, they do not need an additional
mitigation instruction for the forwarded result. We handle this
common case by adding additional patterns that allow for this.
gcc/ChangeLog:
* config/arm/crypto.md (crypto_<CRYPTO_AESMC:crypto_pattern>_protected):
New pattern.
(aarch32_crypto_aese_fused_protected): Likewise.
(aarch32_crypto_aesd_fused_protected): Likewise.
This patch adds the basic patterns for mitigation of the erratum, but no
attempt is made at this point to optimize the results for the cases where
the erratum mitigation is not needed.
The mitigation is done by guaranteeing that the input operands are fed
from a full-width operation by using an identity operation on the input
values.
gcc/ChangeLog:
* config/arm/crypto.md (crypto_<CRYPTO_AES:crypto_pattern>): Convert
to define_expand. Add mitigation for the Cortex-A AES erratum
when enabled.
(*crypto_<CRYPTO_AES:crypto_pattern>_insn): New pattern, based
on original crypto_<CRYPTO_AES:crypto_pattern> insn.
(aes_op_protect): New pattern.
* config/arm/unspecs.md (unspec): Add UNSPEC_AES_PROTECT.
Add a new option -mfix-cortex-a-aes for enabling the Cortex-A AES
erratum work-around and enable it automatically for the affected
products (Cortex-A57 and Cortex-A72).
gcc/ChangeLog:
* config/arm/arm-cpus.in (quirk_aes_1742098): New quirk feature
(ALL_QUIRKS): Add it.
(cortex-a57, cortex-a72): Enable it.
(cortex-a57.cortex-a53, cortex-a72.cortex-a53): Likewise.
* config/arm/arm.opt (mfix-cortex-a57-aes-1742098): New command-line
option.
(mfix-cortex-a72-aes-1655431): New option alias.
* config/arm/arm.cc (arm_option_override): Handle default settings
for AES erratum switch.
* doc/invoke.texi (Arm Options): Document new options.
A couple of patterns in the crypto support code were hard-coding the
mode rather than using the iterators. While not incorrect, it was
slightly confusing, so adapt those patterns to the style of the rest
of the file.
Also fix some white space issues.
gcc/ChangeLog:
* config/arm/crypto.md (crypto_<CYRPTO_AES:crypto_pattern>): Use
<crypto_mode> rather than hard-coding the mode.
(crypto_<CRYPTO_AESMC:crypto_pattern>): Fix white space.
(crypto_<CRYPTO_AES:crypto_pattern>): Likewise.
(*aarch32_crypto_aese_fused): Likewise.
(*aarch32_crypto_aesd_fused): Likewise.
(crypto_<CRYPTO_BINARY:crypto_pattern>): Likewise.
(crypto_<CRYPTO_TERNARY:crypto_pattern>): Likewise.
(crypto_sha1h_lb): Likewise.
(crypto_vmullp64): Likewise.
(crypto_<CRYPTO_SELECTING:crypto_pattern>): Likewise.
(crypto_<CRYPTO_SELECTING:crypto_pattern>_lb): Likewise.
No functional change, but arm/crypto.md has multiple pattenrs all
called crypto_<crypto_pattern>, which makes references to them
ambiguous, so add the iterator base to the pattern name so that it is
distinct in the commit logs.
gcc/ChangeLog:
* config/arm/crypto.md (crypto_<CRYPTO_AESMC:crypto_pattern>): Add
iterator to pattern name to disambiguate.
(crypto_<CRYPTO_AES:crypto_pattern>): Likewise.
(crypto_<CRYPTO_BINARY:crypto_pattern>): Likewise.
(crypto_<CRYPTO_TERNARY:crypto_pattern>): Likewise.
(crypto_<CRYPTO_SELECTING:crypto_pattern>): Likewise.
(crypto_<CRYPTO_SELECTING:crypto_pattern>_lb): Likewise.
riscv*-*-* are the only modern targets that !HAVE_AS_LEB128 (apparently
due to some aggressive linker optimizations).
As the following testcase shows, we mishandle in index_rnglists the
!HAVE_AS_LEB128 && !have_multiple_function_sections case.
output_rnglists does roughly:
FOR_EACH_VEC_SAFE_ELT (ranges_table, i, r)
{
...
if (block_num > 0)
{
...
if (HAVE_AS_LEB128)
{
if (!have_multiple_function_sections)
{
// code not using r->*_entry
continue;
}
// code that sometimes doesn't use r->*_entry,
// sometimes r->begin_entry
}
else if (dwarf_split_debug_info)
{
// code that uses both r->begin_entry and r->end_entry
}
else
{
// code not using r->*_entry
}
}
else if (block_num < 0)
{
if (!have_multiple_function_sections)
gcc_unreachable ();
...
}
}
and index_rnglists is what sets up those r->{begin,end}_entry members.
The code did an early if (!have_multiple_function_sections) continue;
which is fine for the HAVE_AS_LEB128 case, because r->*_entry is not
used in that case, but not for !HAVE_AS_LEB128 that uses it anyway.
2022-01-20 Jakub Jelinek <jakub@redhat.com>
PR debug/103874
* dwarf2out.cc (index_rnglists): For !HAVE_AS_LEB128 and
block_num > 0, index entry even if !have_multiple_function_sections.
* gcc.dg/debug/dwarf2/pr103874.c: New test.
This patch fixes
gcc/testsuite/g++.dg/opt/pr47639.C:6:24: warning: MMX vector return without MMX enabled changes the ABI [-Wpsabi]
gcc/testsuite/g++.dg/opt/pr47639.C:6:5: warning: MMX vector argument without MMX enabled changes the ABI [-Wpsabi]
FAILs on i686-linux.
2022-01-20 Jakub Jelinek <jakub@redhat.com>
* g++.dg/opt/pr47639.C: Add -Wno-psabi to dg-options.
For testcase in PR, the patch supports QI:4 -> HI:16 pack with
multi steps(first pack QI:4 -> QI:8 through vec_pack_sbool_trunc_qi,
then pack QI:8 -> HI:16 through vec_pack_trunc_hi).
Similar for QI:2 -> HI:16 which is test4 in mask-pack-prefer-128.c.
gcc/ChangeLog:
PR target/103771
* tree-vect-stmts.cc (supportable_narrowing_operation): Enhance
integral mode mask pack by multi steps which takes
vec_pack_sbool_trunc_optab as start when elements number is
less than BITS_PER_UNITS.
gcc/testsuite/ChangeLog:
* gcc.target/i386/mask-pack-prefer128.c: New test.
* gcc.target/i386/mask-pack-prefer256.c: New test.
* gcc.target/i386/pr103771.c: New test.
Currently we diagnose vector lowering of V1mode operations that
are not natively supported into V_C_E, scalar op plus CTOR with
-Wvector-operation-performance but that's hardly useful behavior
even though the way we lower things can be improved.
The following disables the diagnostics for the cases the vect.exp
testsuite runs into, on x86 that are vect-cond-11.c and
vect-singleton_1.c.
2022-01-19 Richard Biener <rguenther@suse.de>
PR tree-optimization/104114
* tree-vect-generic.cc (expand_vector_piecewise): Do not diagnose
single element vector decomposition.
The patch for PR41723 properly changed one place to look into the current
instantiation; now we need to fix this place as well.
PR c++/102300
gcc/cp/ChangeLog:
* parser.cc (cp_parser_template_name): Use dependent_scope_p.
gcc/testsuite/ChangeLog:
* g++.dg/parse/no-typename1.C: Remove expected error.
* g++.dg/template/nested7.C: New test.
The default is -gdwarf-5 now, so this is hurting rather than improving
things.
libstdc++-v3/ChangeLog:
* configure.ac (GLIBCXX_ENABLE_DEBUG_FLAGS): Remove -gdwarf-4
from default flags.
* configure: Regenerate.
If one of the to-be-converted SETs requires the original comparison
(i.e. in order to generate a min/max insn) but no other insn after it
does, we can omit creating temporaries, thus facilitating costing.
gcc/ChangeLog:
* ifcvt.cc (noce_convert_multiple_sets_1): New function.
(noce_convert_multiple_sets): Call function a second time if we can
improve the first try.
Add new s390-specific tests that check if we convert two SETs into two
loads on condition. Remove the s390-specific target-check in
gcc.dg/ifcvt-4.c.
gcc/testsuite/ChangeLog:
* gcc.dg/ifcvt-4.c: Remove s390-specific check.
* gcc.target/s390/ifcvt-two-insns-bool.c: New test.
* gcc.target/s390/ifcvt-two-insns-int.c: New test.
* gcc.target/s390/ifcvt-two-insns-long.c: New test.
Following up on the previous patch, this patch makes
noce_convert_multiple emit two cmov sequences: The same one as before
and a second one that tries to re-use the existing CC. Then their costs
are compared and the cheaper one is selected.
gcc/ChangeLog:
* ifcvt.cc (cond_exec_get_condition): New parameter to allow getting the
reversed comparison.
(try_emit_cmove_seq): New function to facilitate creating a cmov
sequence.
(noce_convert_multiple_sets): Create two sequences and use the less
expensive one.
Currently we only ever call emit_conditional_move with the comparison
(as well as its comparands) we got from the jump. Thus, backends are
going to emit a CC comparison for every conditional move that is being
generated instead of re-using the existing CC.
This, combined with emitting temporaries for each conditional move,
causes sky-high costs for conditional moves.
This patch allows to re-use a CC so the costing situation is improved a
bit.
gcc/ChangeLog:
* rtl.h (struct rtx_comparison): New struct that holds an rtx
comparison.
* config/rs6000/rs6000.cc (rs6000_emit_minmax): Use struct instead of
single parameters.
(rs6000_emit_swsqrt): Likewise.
* expmed.cc (expand_sdiv_pow2): Likewise.
(emit_store_flag): Likewise.
* expr.cc (expand_cond_expr_using_cmove): Likewise.
(expand_expr_real_2): Likewise.
* ifcvt.cc (noce_emit_cmove): Add compare and reversed compare
parameters.
* optabs.cc (emit_conditional_move_1): New function.
(expand_doubleword_shift_condmove): Use struct.
(emit_conditional_move): Use struct and allow to call directly
without going through preparation steps.
* optabs.h (emit_conditional_move): Use struct.
When noce_convert_multiple is called the original costs are not yet
initialized. Therefore, up to now, costs were only ever unfairly
compared against COSTS_N_INSNS (2). This would lead to
default_noce_conversion_profitable_p () rejecting all but the most
contrived of sequences.
This patch temporarily initializes the original costs by counting
adding costs for all sets inside the then_bb.
gcc/ChangeLog:
* ifcvt.cc (bb_ok_for_noce_convert_multiple_sets): Estimate insns costs.
(noce_process_if_block): Use potential costs.
This lifts the restriction of not allowing constants for
noce_convert_multiple. The code later checks if a valid sequence
is produced anyway.
gcc/ChangeLog:
* ifcvt.cc (noce_convert_multiple_sets): Allow constants.
(bb_ok_for_noce_convert_multiple_sets): Likewise.
When if-converting multiple SETs and we encounter a swap-style idiom
if (a > b)
{
tmp = c; // [1]
c = d;
d = tmp;
}
ifcvt should not generate a conditional move for the instruction at
[1].
In order to achieve that, this patch goes through all relevant SETs
and marks the relevant instructions. This helps to evaluate costs.
On top, only generate temporaries if the current cmov is going to
overwrite one of the comparands of the initial compare.
gcc/ChangeLog:
* ifcvt.cc (need_cmov_or_rewire): New function.
(noce_convert_multiple_sets): Call it.
This makes it possible to combine --enable-libstdcxx-debug with
--enable-libstdcxx-backtrace, by adding a rule to src/Makefile to copy
the backtrace-supported.h header into the src/debug/libbacktrace
directory.
Add libbacktrace path to testsuite flags so the tests can link without
having the library installed.
Also fix some warnings when running automake for the libbacktrace
makefile.
Use a per-library CPPFLAGS variable to fix:
src/libbacktrace/Makefile.am:38: warning: AM_CPPFLAGS multiply defined in condition TRUE ...
fragment.am:43: ... 'AM_CPPFLAGS' previously defined here
src/libbacktrace/Makefile.am:32: 'fragment.am' included from here
Create symlinks to the libbacktrace sources to fix:
src/libbacktrace/Makefile.am:55: warning: source file '../../../libbacktrace/atomic.c' is in a subdirectory,
src/libbacktrace/Makefile.am:55: but option 'subdir-objects' is disabled
libstdc++-v3/ChangeLog:
* scripts/testsuite_flags.in: Add src/libbacktrace/.libs to
linker search paths.
* src/Makefile.am: Fix src/debug/libbacktrace build.
* src/Makefile.in: Regenerate.
* src/libbacktrace/Makefile.am: Use per-library CPPFLAGS
variable. Use symlinks for the source files.
* src/libbacktrace/Makefile.in: Regenerate.
power10 has modv4si3 expander and so vectorizes the following testcase
where Fortran modulo is FLOOR_MOD_EXPR.
optabs_for_tree_code indicates that the optab for all the *_MOD_EXPR
variants is umod_optab or smod_optab, but that isn't true, that optab
actually expands just TRUNC_MOD_EXPR. For the other tree codes expmed.cc
has code how to adjust the TRUNC_MOD_EXPR into those by emitting some
extra comparisons and conditional updates. Similarly for *_DIV_EXPR,
except in that case it actually needs both division and modulo.
While it would be possible to handle it in expmed.cc for vectors as well,
we'd need to be sure all the vector operations we need for that are
available, and furthermore we wouldn't account for that in the costing.
So, IMHO it is better to stop pretending those non-truncating (and
non-exact) div/mod operations have an optab. For GCC 13, we should
IMHO pattern match these in tree-vect-patterns.cc and transform them
to truncating div/mod with follow-up adjustments and let the vectorizer
vectorize that. As written in the PR, for signed operands:
r = x %[fl] y;
is
r = x % y; if (r && (x ^ y) < 0) r += y;
and
d = x /[fl] y;
is
r = x % y; d = x / y; if (r && (x ^ y) < 0) --d;
and
r = x %[cl] y;
is
r = x % y; if (r && (x ^ y) >= 0) r -= y;
and
d = /[cl] y;
is
r = x % y; d = x / y; if (r && (x ^ y) >= 0) ++d;
(too lazy to figure out rounding div/mod now). I'll create a PR
for that.
The patch also extends a match.pd optimization that floor_mod on
unsigned operands is actually trunc_mod.
2022-01-19 Jakub Jelinek <jakub@redhat.com>
PR middle-end/102860
* match.pd (x %[fl] y -> x % y): New simplification for
unsigned integral types.
* optabs-tree.cc (optab_for_tree_code): Return unknown_optab
for {CEIL,FLOOR,ROUND}_{DIV,MOD}_EXPR with VECTOR_TYPE.
* gfortran.dg/pr102860.f90: New test.
The testcase from the PR got fixed with r12-3119-g675a3e40567e1d
and looks quite similar to the evrp-trans.c test, except evrp-trans.c
is tested on signed integer types.
I think it would be useful to test it for unsigned comparisons too.
2022-01-19 Jakub Jelinek <jakub@redhat.com>
PR c/104115
* gcc.dg/tree-ssa/evrp-trans2.c: New test.
This adds a missing check for the availability of intermediate vector
types required to re-use the accumulator of a vectorized reduction
in the vectorized epilogue. For SVE and VNx2DF vs V2DF with
-msve-vector-bits=512 for example V4DF is not available.
In addition to that we have to verify the reduction operation is
supported, otherwise we for example on i?86 get vector code that's
later decomposed again by vector lowering when trying to use
a V2HI epilogue for a V8HI reduction with a target without
TARGET_MMX_WITH_SSE.
It might be we want -Wvector-operation-performance for all vect.exp
tests but that seems to have existing regressions.
2022-01-19 Richard Biener <rguenther@suse.de>
PR tree-optimization/104112
* tree-vect-loop.cc (vect_find_reusable_accumulator): Check
for required intermediate vector types.
* gcc.dg/vect/pr104112-1.c: New testcase.
* gcc.dg/vect/pr104112-2.c: New testcase.
Currently omp_get_device_num does not work on gcn targets with more than one
offload device. The reason is that GOMP_DEVICE_NUM_VAR is static in
icv-device.c and thus "__gomp_device_num" is not visible in the offload image.
This patch removes "static" such that "__gomp_device_num" is now part of the
offload image and can now be found in GOMP_OFFLOAD_load_image in the plugin.
This is not an issue for nvptx. There, "__gomp_device_num" is in the offload
image even with "static".
libgomp/ChangeLog:
* config/gcn/icv-device.c: Make GOMP_DEVICE_NUM_VAR public (remove
"static") to make the device num available in the offload image.
Use SFINAE magic to support: "It is unspecified whether math_errhandling
is a macro or an identifier with external linkage." [C Standard]
Signed-off-by: Matthias Kretz <m.kretz@gsi.de>
libstdc++-v3/ChangeLog:
* include/experimental/bits/simd.h (__floating_point_flags): Do
not rely on math_errhandling to expand to a constant expression.
Since the x86_64-linux-gnux32 compiler is actually an x32 compiler, set
target_cpu to x32 for x86_64-linux-gnux32.
PR ada/103538
* gcc-interface/Makefile.in (target_cpu): Set to x32 for
x86_64-linux-gnux32.
The tests are C++ code, so use a proper file extension.
gcc/testsuite/ChangeLog:
* g++.dg/ext/boolcomplex-1.c: Moved to...
* g++.dg/ext/boolcomplex-1.C: ...here.
* g++.dg/opt/pr47639.c: Moved to...
* g++.dg/opt/pr47639.C: ...here.
* g++.dg/pr83979.c: Moved to...
* g++.dg/pr83979.C: ...here.
* g++.dg/tm/asm-1.c: Moved to...
* g++.dg/tm/asm-1.C: ...here.
* g++.dg/vect/pr71483.c: Moved to...
* g++.dg/vect/pr71483.cc: ...here.
> On 18/01/2022 22:42, Segher Boessenkool wrote:
> > > + default:
> > > + break;
> > Please don't do that. You can do
> >
> > default:
> > break;
> > break;
> > /* And just to make sure: */
> > break;
> > break;
> >
> > and it will do exactly the same as not having a default at all. Not
> > having such useless code is by far the most readable, so please don't
> > include a default case at all.
>
> I removed the default case. I hope this is what you wanted.
Unfortunately the removal of default: break; breaks bootstrap:
../../gcc/config/rs6000/rs6000.cc: In function ‘const char* rs6000_machine_from_flags()’:
../../gcc/config/rs6000/rs6000.cc:5940:10: error: enumeration value ‘PROCESSOR_PPC601’ not handled in switch [-Werror=switch]
5940 | switch (rs6000_cpu)
| ^
../../gcc/config/rs6000/rs6000.cc:5940:10: error: enumeration value ‘PROCESSOR_PPC603’ not handled in switch [-Werror=switch]
...
default: break; is needed to tell the -Wswitch warning that it is intentional
that not all enumerators are handled in the switch.
2022-01-19 Jakub Jelinek <jakub@redhat.com>
* config/rs6000/rs6000.cc (rs6000_machine_from_flags): Add default:.
As reported in the PR or as I've seen since the weekend, asan_test.C fails
because of many warnings like:
gcc/testsuite/g++.dg/asan/asan_test.cc:1157:10: error: using a dangling pointer to an unnamed temporary [-Werror=dangling-pointer=]
gcc/testsuite/g++.dg/asan/asan_test.cc:1157:10: error: using a dangling pointer to an unnamed temporary [-Werror=dangling-pointer=]
gcc/testsuite/g++.dg/asan/asan_test.cc:1162:27: error: using a dangling pointer to an unnamed temporary [-Werror=dangling-pointer=]
...
(lots of them).
There are no dangling pointers though, the warning pass sees:
some_automatic_var ={v} {CLOBBER};
.ASAN_MARK (POISON, &some_automatic_var, 8);
and warns on that (both on user vars and on e.g. TARGET_EXPR temporaries).
There is nothing wrong on that, .ASAN_MARK is compiler instrumentation,
which doesn't even touch the variable in any way nor make it escaped.
What it instead does is change bytes in the shadow memory corresponding
to the variable to reflect that the variable is out of scope and make
sure that access to it would be diagnosed at runtime.
So, for all purposes of the -Wdangling-pointer and -Wuse-after-free
warnings, we should ignore this internal call.
2022-01-19 Jakub Jelinek <jakub@redhat.com>
PR middle-end/104103
* gimple-ssa-warn-access.cc (pass_waccess::check_call): Don't check
.ASAN_MARK calls.
This is a non-C++ related part from the PR89074 address_compare changes.
For "foo" == "foo" we already optimize this from the (cmp @0 @0)
simplification, because we use operand_equal_p in that case
and operand_equal_p also compares the STRING_CSTs bytes rather than
just addresses.
2022-01-19 Jakub Jelinek <jakub@redhat.com>
PR c++/89074
* fold-const.cc (address_compare): Consider different STRING_CSTs
with the same lengths that memcmp the same as equal, not different.
* gcc.dg/tree-ssa/pr89074.c: New test.
grep '{[^|}]*}"' *.md
found another spot, though dunno if we have sufficient effective targets
etc. to add an -masm=intel test for it (and my installed binutils doesn't
support it anyway).
Binutils trunk testsuite shows the argument isn't omitted even in the Intel
syntax:
grep aesencwide *.s
keylocker.s: aesencwide128kl 126(%edx)
keylocker.s: aesencwide256kl 126(%edx)
keylocker.s: aesencwide128kl [edx+126]
keylocker.s: aesencwide256kl [edx+126]
property-10.s: aesencwide128kl (%eax)
x86-64-keylocker.s: aesencwide128kl 126(%rdx)
x86-64-keylocker.s: aesencwide256kl 126(%rdx)
x86-64-keylocker.s: aesencwide128kl [rdx+126]
x86-64-keylocker.s: aesencwide256kl [rdx+126]
and doesn't use any WHATEVER PTR.
2022-01-19 Jakub Jelinek <jakub@redhat.com>
* config/i386/sse.md (*aes<aeswideklvariant>u*): Use %0 instead of
{%0}.