Jakub Jelinek [Wed, 3 May 2023 20:31:40 +0000 (22:31 +0200)]
libstdc++: Fix up abi.exp FAILs on powerpc64-linux
As discussed on IRC, my _Float128/_Float64x support changes broke
abi.exp testing on powerpc64-linux.
The
_ZTIDF128_@@CXXABI_1.3.14
_ZTIDF64x@@CXXABI_1.3.14
_ZTIPDF128_@@CXXABI_1.3.14
_ZTIPDF64x@@CXXABI_1.3.14
_ZTIPKDF128_@@CXXABI_1.3.14
_ZTIPKDF64x@@CXXABI_1.3.14
symbols only appear on powerpc64le-linux (both when building against
very old glibcs as well as contemporary glibcs), while they don't
appear on powerpc64-linux, because the latter never has _Float128 or
_Float64x support.
But we were using the same baseline_symbols.txt file for both
powerpc64-linux and powerpc64le-linux, even when it contained quite a lot
of stuff specific to the latter; but that was just the IEEE128 related
stuff that appears only when configured against not very old glibc.
The following patch keeps those exports as is and just splits the
config/abi/post/ files, copies the current one to powerpc64le-linux
unmodified and removes the above mentioned symbols plus all
GLIBCXX_IEEE128_3.4.{29,30,31} and CXXABI_IEEE128_1.3.13 symbols
from the powerpc64-linux version.
2023-05-03 Jakub Jelinek <jakub@redhat.com>
* configure.host (abi_baseline_pair): Use powerpc64le-linux-gnu
rather than powerpc64-linux-gnu for powerpc64le*-linux*.
* config/abi/post/powerpc64-linux-gnu/baseline_symbols.txt: Remove
_ZTI*DF128_, _ZTI*DF64x symbols and symbols in
GLIBCXX_IEEE128_3.4.{29,30,31} and CXXABI_IEEE128_1.3.13 symbol
versions.
* config/abi/post/powerpc64le-linux-gnu/baseline_symbols.txt: New
file.
Jason Merrill [Wed, 3 May 2023 17:32:55 +0000 (13:32 -0400)]
c++: over-eager friend matching [PR109649]
A bug in the simplification I did around 91618; at this point X<int>::f has
DECL_IMPLICIT_INSTANTIATION set, but we've already identified what template
it corresponds to, so we don't want to call check_explicit_specialization.
To distinguish this case we need to look at DECL_TI_TEMPLATE. grokfndecl
has for a long time set it to the OVERLOAD in this case, while the new cases
I added for 91618 were leaving DECL_TEMPLATE_INFO null; let's adjust them to
match.
PR c++/91618
PR c++/109649
gcc/cp/ChangeLog:
* friend.cc (do_friend): Don't call check_explicit_specialization if
DECL_TEMPLATE_INFO is already set.
* decl2.cc (check_classfn): Set DECL_TEMPLATE_INFO.
* name-lookup.cc (set_decl_namespace): Likewise.
Andrew Pinski [Tue, 2 May 2023 07:08:19 +0000 (00:08 -0700)]
Add stats to simple_dce_from_worklist
While looking to move substitute_and_fold_engine
over to use simple_dce_from_worklist, I noticed
that we don't record the stats of the removed stmts/phis.
So this does that.
OK? Bootstrapped and tested on x86_64-linux-gnu.
gcc/ChangeLog:
* tree-ssa-dce.cc (simple_dce_from_worklist): Record
stats on removed number of statements and phis.
Aldy Hernandez [Wed, 3 May 2023 15:29:24 +0000 (17:29 +0200)]
Allow varying ranges of unknown types in irange::verify_range [PR109711]
The old legacy code allowed building ranges of unknown types so passes
like IPA could build and propagate VARYING. For now it's easiest to
allow the old behavior, it's not like you can do anything with these
ranges except build them and copy them.
Eventually we should convert all users of set_varying() to use
supported types. I will address this in my upcoming IPA work.
PR tree-optimization/109711
gcc/ChangeLog:
* value-range.cc (irange::verify_range): Allow types of
error_mark_node.
do not tailcall __sanitizer_cov_trace_pc [PR90746]
When instrumentation is requested via -fsanitize-coverage=trace-pc, GCC
emits calls of __sanitizer_cov_trace_pc callback in each basic block.
This callback is supposed to be implemented by the user, and should be
able to identify the containing basic block by inspecting its return
address. Tailcalling the callback prevents that, so disallow it.
gcc/ChangeLog:
PR sanitizer/90746
* calls.cc (can_implement_as_sibling_call_p): Reject calls
to __sanitizer_cov_trace_pc.
gcc/testsuite/ChangeLog:
PR sanitizer/90746
* gcc.dg/sancov/basic0.c: Verify absence of tailcall.
aarch64: Fix ABI handling of aligned enums [PR109661]
aarch64_function_arg_alignment has traditionally taken the alignment
of a scalar type T from TYPE_ALIGN (TYPE_MAIN_VARIANT (T)). This is
supposed to discard any user alignment and give the alignment of the
underlying fundamental type.
PR109661 shows that this did the wrong thing for enums with
a defined underlying type, because:
(1) The enum itself could be aligned, using attributes.
(2) The enum would pick up any user alignment on the underlying type.
We get the right behaviour if we look at the TYPE_MAIN_VARIANT
of the underlying type instead.
As always, this affects register and stack arguments differently,
because:
(a) The code that handles register arguments only considers the
alignment of types that occupy two registers, whereas the
stack alignment is applied regardless of size.
(b) The code that handles register arguments tests the alignment
for equality with 16 bytes, so that (unexpected) greater alignments
are ignored. The code that handles stack arguments instead caps the
alignment to 16 bytes.
There is now (since GCC 13) an assert to trap the difference between
(a) and (b), which is how the new incompatiblity showed up.
Clang alredy handled the testcases correctly, so this patch aligns
the GCC behaviour with the Clang behaviour.
I'm planning to remove the asserts on the branches, since we don't
want to change the ABI there.
gcc/
PR target/109661
* config/aarch64/aarch64.cc (aarch64_function_arg_alignment): Add
a new ABI break parameter for GCC 14. Set it to the alignment
of enums that have an underlying type. Take the true alignment
of such enums from the TYPE_ALIGN of the underlying type's
TYPE_MAIN_VARIANT.
(aarch64_function_arg_boundary): Update accordingly.
(aarch64_layout_arg, aarch64_gimplify_va_arg_expr): Likewise.
Warn about ABI differences.
aarch64_function_arg_alignment has two related abi_break
parameters: abi_break for a change in GCC 9, and abi_break_packed
for a related follow-on change in GCC 13. In a sense, abi_break_packed
is a "subfix" of abi_break.
PR109661 now requires a third ABI break that is independent
of the other two. Having abi_break for the GCC 9 break and
abi_break_<something> for the GCC 13 and GCC 14 breaks might
give the impression that they're all related, and that the GCC 14
fix (like the GCC 13 fix) is a "subfix" of the GCC 9 one.
It therefore seemed like a good idea to rename the existing
variables first.
It would be difficult to choose names that describe briefly and
precisely what went wrong in each case. The next best thing
seemed to be to name them after the relevant GCC version.
(Of course, this might break down in future if we need two
independent fixes in the same version. Let's hope not.)
I wondered about putting all the variables in a structure,
but one advantage of using independent variables is that it's
harder to forget to update a caller. Maybe a fourth parameter
would be a tipping point.
gcc/
PR target/109661
* config/aarch64/aarch64.cc (aarch64_function_arg_alignment): Rename
ABI break variables to abi_break_gcc_9 and abi_break_gcc_13.
(aarch64_layout_arg, aarch64_function_arg_boundary): Likewise.
(aarch64_gimplify_va_arg_expr): Likewise.
Christophe Lyon [Tue, 7 Feb 2023 19:26:29 +0000 (19:26 +0000)]
arm: [MVE intrinsics] factorize several binary operations
Factorize vabdq, vhaddq, vhsubq, vmulhq, vqaddq_u, vqdmulhq,
vqrdmulhq, vqrshlq, vqshlq, vqsubq_u, vrhaddq, vrmulhq, vrshlq
so that they use the same pattern.
Christophe Lyon [Tue, 7 Feb 2023 19:15:45 +0000 (19:15 +0000)]
arm: [MVE intrinsics] factorize several binary _m_n operations
Factorize vhaddq_m_n, vhsubq_m_n, vmlaq_m_n, vmlasq_m_n, vqaddq_m_n,
vqdmlahq_m_n, vqdmlashq_m_n, vqdmulhq_m_n, vqrdmlahq_m_n,
vqrdmlashq_m_n, vqrdmulhq_m_n, vqsubq_m_n
so that they use the same pattern.
Christophe Lyon [Wed, 15 Feb 2023 14:38:49 +0000 (14:38 +0000)]
arm: [MVE intrinsics] factorize several binary_m operations
Factorize m-predicated versions of vabdq, vhaddq, vhsubq, vmaxq,
vminq, vmulhq, vqaddq, vqdmladhq, vqdmladhxq, vqdmlsdhq, vqdmlsdhxq,
vqdmulhq, vqrdmladhq, vqrdmladhxq, vqrdmlsdhq, vqrdmlsdhxq, vqrdmulhq,
vqrshlq, vqshlq, vqsubq, vrhaddq, vrmulhq, vrshlq, vshlq
so that they use the same pattern.
Christophe Lyon [Mon, 20 Feb 2023 14:04:29 +0000 (14:04 +0000)]
arm: [MVE intrinsics] add binary_orrq shape
patch adds the binary_orrq shape description.
MODE_n intrinsics use a set of predicates (preds_m_or_none) different
the MODE_none ones, so we explicitly reference preds_m_or_none from
the shape, thus we need to make it a global array.
In order to avoid using a huge switch when generating all the
intrinsics (e.g. mve_vaddq_n_sv4si, ...), we want to generate a single
function taking the builtin code as parameter (e.g. mve_q_n (VADDQ_S,
....)
This is achieved by using the new mve_insn iterator.
Having done that, it becomes easier to share similar patterns, to
avoid useless/error-prone code duplication.
Christophe Lyon [Thu, 11 Aug 2022 16:15:03 +0000 (16:15 +0000)]
arm: [MVE intrinsics] Rework vuninitialized
Implement vuninitialized using the new MVE builtins framework.
We need to keep the overloaded __arm_vuninitializedq definitions
because their resolution depends on the result type only, which is not
currently supported by the resolver.
gcc/testsuite/
* g++.target/arm/mve.exp: Add general-c++ and general directories.
* g++.target/arm/mve/general-c++/nomve_fp_1.c: New test.
* g++.target/arm/mve/general-c++/vreinterpretq_1.C: New test.
* gcc.target/arm/mve/general-c/nomve_fp_1.c: New test.
* gcc.target/arm/mve/general-c/vreinterpretq_1.c: New test.
This patch introduces the new MVE intrinsics framework, heavily
inspired by the SVE one in the aarch64 port.
Like the MVE intrinsic types implementation, the intrinsics framework
defines functions via a new pragma in arm_mve.h. A boolean parameter
is used to pass true when __ARM_MVE_PRESERVE_USER_NAMESPACE is
defined, and false when it is not, allowing for non-prefixed intrinsic
functions to be conditionally defined.
Future patches will build on this framework by adding new intrinsic
functions and adding the features needed to support them.
Differences compared to the aarch64/SVE port include:
- when present, the predicate argument is the last one with MVE (the
first one with SVE)
- when using merging predicates ("_m" suffix), the "inactive" argument
(if any) is inserted in the first position
- when using merging predicates ("_m" suffix), some function do not
have the "inactive" argument, so we maintain an exception-list
- MVE intrinsics dealing with floating-point require the FP extension,
while SVE may support different extensions
- regarding global state, MVE does not have any prefetch intrinsic, so
we do not need a flag for this
- intrinsic names can be prefixed with "__arm", depending on whether
preserve_user_namespace is true or false
- parse_signature: the maximum number of arguments is now a parameter,
this helps detecting an overflow with a new assert.
- suffixes and overloading can be controlled using
explicit_mode_suffix_p and skip_overload_p in addition to
explicit_type_suffix_p
At this implemtation stage, there are some limitations compared
to aarch64/SVE, which are removed later in the series:
- "offset" mode is not supported yet
- gimple folding is not implemented
arm: move builtin function codes into general numberspace
This patch introduces a separate numberspace for general arm builtin
function codes. The intent of this patch is to separate the space of
function codes that may be assigned to general builtins and future
MVE intrinsic functions by using the first bit of each function code
to differentiate them. This is identical to how SVE intrinsic functions
are currently differentiated from general aarch64 builtins.
Future intrinsics implementations may also make use of numberspacing by
changing the values of ARM_BUILTIN_SHIFT and ARM_BUILTIN_CLASS, and
adding themselves to the arm_builtin_class enum.
* config/arm/arm-builtins.cc (arm_general_add_builtin_function):
New function.
(arm_init_builtin): Use arm_general_add_builtin_function instead
of arm_add_builtin_function.
(arm_init_acle_builtins): Likewise.
(arm_init_mve_builtins): Likewise.
(arm_init_crypto_builtins): Likewise.
(arm_init_builtins): Likewise.
(arm_general_builtin_decl): New function.
(arm_builtin_decl): Defer to numberspace-specialized functions.
(arm_expand_builtin_args): Rename into arm_general_expand_builtin_args.
(arm_expand_builtin_1): Rename into arm_general_expand_builtin_1 and ...
(arm_general_expand_builtin_1): ... specialize for general builtins.
(arm_expand_acle_builtin): Use arm_general_expand_builtin
instead of arm_expand_builtin.
(arm_expand_mve_builtin): Likewise.
(arm_expand_neon_builtin): Likewise.
(arm_expand_vfp_builtin): Likewise.
(arm_general_expand_builtin): New function.
(arm_expand_builtin): Specialize for general builtins.
(arm_general_check_builtin_call): New function.
(arm_check_builtin_call): Specialize for general builtins.
(arm_describe_resolver): Validate numberspace.
(arm_cde_end_args): Likewise.
* config/arm/arm-protos.h (enum arm_builtin_class): New enum.
(ARM_BUILTIN_SHIFT, ARM_BUILTIN_CLASS): New constants.
Martin Liska [Wed, 3 May 2023 14:35:26 +0000 (16:35 +0200)]
riscv: fix error: control reaches end of non-void function
Fixes:
gcc/config/riscv/sync.md:66:1: error: control reaches end of non-void function [-Werror=return-type]
66 | [(set (attr "length") (const_int 4))])
| ^
PR target/109713
gcc/ChangeLog:
* config/riscv/sync.md: Add gcc_unreachable to a switch.
Richard Biener [Wed, 3 May 2023 11:24:45 +0000 (13:24 +0200)]
More last_stmt removal
This is the last set of changes removing calls to last_stmt in favor of
*gsi_last_bb where this is obviously correct. As with the last changes
I tried to cleanup the code as far as dependences are concerned.
Kefu Chai [Mon, 1 May 2023 20:24:26 +0000 (21:24 +0100)]
libstdc++: Set _M_string_length before calling _M_dispose() [PR109703]
This always sets _M_string_length in the constructor for ranges of input
iterators, such as stream iterators.
We copy from the source range to the local buffer, and then repeatedly
reallocate a larger one if necessary. When disposing the old buffer,
_M_is_local() is used to tell if the buffer is the local one or not (and
so must be deallocated). In addition to comparing the buffer address
with the local buffer, _M_is_local() has an optimization hint so that
the compiler knows that for a string using the local buffer, there is an
invariant that _M_string_length <= _S_local_capacity (added for PR109299
via r13-6915-gbf78b43873b0b7). But we failed to set _M_string_length in
the constructor taking a pair of iterators, so the invariant might not
hold, and __builtin_unreachable() is reached. This causes UBsan errors,
and potentially misoptimization.
To ensure the invariant holds, _M_string_length is initialized to zero
before doing anything else, so that _M_is_local() doesn't see an
uninitialized value.
This issue only surfaces when constructing a string with a range of
input iterator, and the uninitialized _M_string_length happens to be
greater than _S_local_capacity, i.e., 15 for the std::string
specialization.
Andreas Schwab [Sat, 23 Apr 2022 13:48:42 +0000 (15:48 +0200)]
riscv/linux: Don't add -latomic with -pthread
Now that we have support for inline subword atomic operations, it is no
longer necessary to link against libatomic. This also fixes testsuite
failures because the framework does not properly set up the linker flags
for finding libatomic.
The use of atomic operations is also independent of the use of libpthread.
* gcc.target/riscv/rvv/base/abi-10.c: New test.
* gcc.target/riscv/rvv/base/abi-11.c: New test.
* gcc.target/riscv/rvv/base/abi-12.c: New test.
* gcc.target/riscv/rvv/base/abi-13.c: New test.
* gcc.target/riscv/rvv/base/abi-14.c: New test.
* gcc.target/riscv/rvv/base/abi-15.c: New test.
* gcc.target/riscv/rvv/base/abi-16.c: New test.
* gcc.target/riscv/rvv/base/abi-8.c: New test.
* gcc.target/riscv/rvv/base/abi-9.c: New test.
* gcc.target/riscv/rvv/base/tuple-1.c: New test.
* gcc.target/riscv/rvv/base/tuple-10.c: New test.
* gcc.target/riscv/rvv/base/tuple-11.c: New test.
* gcc.target/riscv/rvv/base/tuple-12.c: New test.
* gcc.target/riscv/rvv/base/tuple-13.c: New test.
* gcc.target/riscv/rvv/base/tuple-14.c: New test.
* gcc.target/riscv/rvv/base/tuple-15.c: New test.
* gcc.target/riscv/rvv/base/tuple-16.c: New test.
* gcc.target/riscv/rvv/base/tuple-17.c: New test.
* gcc.target/riscv/rvv/base/tuple-18.c: New test.
* gcc.target/riscv/rvv/base/tuple-19.c: New test.
* gcc.target/riscv/rvv/base/tuple-2.c: New test.
* gcc.target/riscv/rvv/base/tuple-20.c: New test.
* gcc.target/riscv/rvv/base/tuple-21.c: New test.
* gcc.target/riscv/rvv/base/tuple-22.c: New test.
* gcc.target/riscv/rvv/base/tuple-23.c: New test.
* gcc.target/riscv/rvv/base/tuple-24.c: New test.
* gcc.target/riscv/rvv/base/tuple-25.c: New test.
* gcc.target/riscv/rvv/base/tuple-26.c: New test.
* gcc.target/riscv/rvv/base/tuple-27.c: New test.
* gcc.target/riscv/rvv/base/tuple-3.c: New test.
* gcc.target/riscv/rvv/base/tuple-4.c: New test.
* gcc.target/riscv/rvv/base/tuple-5.c: New test.
* gcc.target/riscv/rvv/base/tuple-6.c: New test.
* gcc.target/riscv/rvv/base/tuple-7.c: New test.
* gcc.target/riscv/rvv/base/tuple-8.c: New test.
* gcc.target/riscv/rvv/base/tuple-9.c: New test.
* gcc.target/riscv/rvv/base/user-10.c: New test.
* gcc.target/riscv/rvv/base/user-11.c: New test.
* gcc.target/riscv/rvv/base/user-12.c: New test.
* gcc.target/riscv/rvv/base/user-13.c: New test.
* gcc.target/riscv/rvv/base/user-14.c: New test.
* gcc.target/riscv/rvv/base/user-15.c: New test.
* gcc.target/riscv/rvv/base/user-7.c: New test.
* gcc.target/riscv/rvv/base/user-8.c: New test.
* gcc.target/riscv/rvv/base/user-9.c: New test.
Richard Biener [Fri, 3 Feb 2023 10:11:15 +0000 (11:11 +0100)]
Speedup cse_insn
When cse_insn prunes src{,_folded,_eqv_here,_related} with the
equivalence set in the *_same_value chain it also searches for
an equivalence to the destination of the instruction with
/* This is the same as the destination of the insns, we want
to prefer it. Copy it to src_related. The code below will
then give it a negative cost. */
if (GET_CODE (dest) == code && rtx_equal_p (p->exp, dest))
src_related = p->exp;
this picks up the last such equivalence and in particular any
later duplicate will be pruned by the preceeding
first. This wastes cycles doing extra rtx_equal_p checks. The
following instead searches for the first destination equivalence
separately in this loop and delays using src_related for it until
we are about to process that, avoiding another redundant rtx_equal_p
check.
I've came here because of a testcase with very large equivalence
lists and compile-time of cse_insn. The patch below doesn't speed
it up significantly since there's no equivalence on the destination.
In theory this opens the possibility to track dest_related
separately, avoiding the implicit pruning of any previous
value in src_related. As is the change should be a no-op for
code generation.
* cse.cc (cse_insn): Track an equivalence to the destination
separately and delay using src_related for it.
Richard Biener [Fri, 3 Feb 2023 11:11:41 +0000 (12:11 +0100)]
Improve RTL CSE hash table hash usage
The RTL CSE hash table has a fixed number of buckets (32) each
with a linked list of entries with the same hash value. The
actual hash values are computed using hash_rtx which uses adds
for mixing and adds the rtx CODE as CODE << 7 (apart from some
exceptions such as MEM). The unsigned int typed hash value
is then simply truncated for the actual lookup into the fixed
size table which means that usually CODE is simply lost.
The following improves this truncation by first mixing in more
bits using xor. It does not change the actual hash function
since that's used outside of CSE as well.
An alternative would be to bump the fixed number of buckets,
say to 256 which would retain the LSB of CODE or to 8192 which
can capture all 6 bits required for the last CODE.
As the comment in CSE says, there's invalidate_memory and
flush_hash_table done possibly frequently and those at least
need to walk all slots, so when the hash table is mostly empty
enlarging it will be a loss. Still there should be more
regular lookups by hash, so less collisions should pay off
as well.
Without enlarging the table a better hash function is unlikely
going to make a big difference, simple statistics on the
number of collisions at insertion time shows a reduction of
around 10%. Bumping HASH_SHIFT by 1 improves that to 30%
at the expense of reducing the average table fill by 10%
(all of this stats from looking just at fold-const.i at -O2).
Increasing HASH_SHIFT more leaves the table even more sparse
likely showing that hash_rtx uses add for mixing which is
quite bad. Bumping HASH_SHIFT by 2 removes 90% of all
collisions.
Experimenting with using inchash instead of adds for the
mixing does not improve things when looking at the HASH_SHIFT
bumped by 2 numbers.
* cse.cc (HASH): Turn into inline function and mix
in another HASH_SHIFT bits.
(SAFE_HASH): Likewise.
Kyrylo Tkachov [Wed, 3 May 2023 10:17:28 +0000 (11:17 +0100)]
aarch64: PR target/99195 annotate HADDSUB patterns for vec-concat with zero
Further straightforward patch for the various halving intrinsics with or without rounding, plus tests.
Bootstrapped and tested on aarch64-none-linux-gnu and aarch64_be-none-elf.
Kyrylo Tkachov [Wed, 3 May 2023 10:15:34 +0000 (11:15 +0100)]
aarch64: PR target/99195 annotate simple floating-point patterns for vec-concat with zero
Continuing the, almost mechanical, series this patch adds annotation for some of the simple
floating-point patterns we have, and adds testing to ensure that redundant zeroing instructions
are eliminated.
Bootstrapped and tested on aarch64-none-linux-gnu and also aarch64_be-none-elf.
PR target/99195
* gcc.target/aarch64/simd/pr99195_1.c: Add testing for some unary
and binary floating-point ops.
* gcc.target/aarch64/simd/pr99195_2.c: New test.
Jakub Jelinek [Wed, 3 May 2023 08:38:04 +0000 (10:38 +0200)]
c++: Fix up VEC_INIT_EXPR gimplification after r12-7069
During patch backporting, I've noticed that while most cp_walk_tree calls
with cp_fold_r callback callers were changed from &pset to cp_fold_data
&data, the VEC_INIT_EXPR gimplifications has not, so it still passes just
address of a hash_set<tree> and so if during the folding we ever touch
data->flags, we use uninitialized data there.
The following patch changes it to do the same thing as cp_fold_function
because the VEC_INIT_EXPR gimplifications will happen on function bodies
only.
2023-05-03 Jakub Jelinek <jakub@redhat.com>
* cp-gimplify.cc (cp_fold_data): Move definition earlier.
(cp_gimplify_expr): Pass address of ff_genericize | ff_mce_false
constructed data rather than &pset to cp_walk_tree with cp_fold_r.
Jason Merrill [Tue, 14 Mar 2023 19:16:46 +0000 (15:16 -0400)]
c++: fix TTP level reduction cache
We try to cache the result of reduce_template_parm_level so that when we
reduce the same parm multiple times we get the same result, but this wasn't
working for template template parms because in that case TYPE is a
TEMPLATE_TEMPLATE_PARM, and so same_type_p was false because of the same
level mismatch that we're trying to adjust for. So in that case compare the
template parms of the template template parms instead.
The result can be seen in nontype12.C, where we previously gave three
duplicate errors on line 7 and now give only one because subsequent
substitutions use the cache.
gcc/cp/ChangeLog:
* pt.cc (reduce_template_parm_level): Fix comparison of
template template parm to cached version.
gcc/testsuite/ChangeLog:
* g++.dg/template/nontype12.C: Check for duplicate error.
Jason Merrill [Tue, 2 May 2023 18:54:46 +0000 (14:54 -0400)]
c++: simplify member template substitution
I noticed that for member class templates of a class template we were
unnecessarily substituting both the template and its type. Avoiding that
duplication speeds compilation of this silly testcase from ~12s to ~9s on my
laptop. It's unlikely to make a difference on any real code, but the
simplification is also nice.
We still need to clear CLASSTYPE_USE_TEMPLATE on the partial instantiation
of the template class, but it makes more sense to do that in
tsubst_template_decl anyway.
Andrew Pinski [Fri, 28 Apr 2023 20:06:51 +0000 (13:06 -0700)]
PHIOPT: small refactoring of match_simplify_replacement.
When I added diamond shaped form bb to match_simplify_replacement,
I copied the code to move the statement rather than factoring it
out to a new function. This does the refactoring to a new function
to avoid the duplicated code. It will make adding support for having
two statements to move easier (the second statement will only be a
conversion).
OK? Bootstrapped and tested on x86_64-linux-gnu.
gcc/ChangeLog:
* tree-ssa-phiopt.cc (move_stmt): New function.
(match_simplify_replacement): Use move_stmt instead
of the inlined version.
Jason Merrill [Tue, 21 Mar 2023 15:12:42 +0000 (11:12 -0400)]
c++: less invalidate_class_lookup_cache
In the testcase below, we push_to_top_level to instantiate f and g, and they
can both use the previous_class_level cache from instantiating A<int>.
Wiping the cache in pop_from_top_level is not helpful; we'll do that in
pushclass if needed.
template <class T> struct A
{
int i;
void f() { i = 42; }
void g() { i = 24; }
};
Jason Merrill [Tue, 2 May 2023 01:03:45 +0000 (21:03 -0400)]
c++: look for empty base at specific offset [PR109678]
While looking at the empty base handling for 109678, it occurred to me that
we ought to be able to look for an empty base at a specific offset, not just
in general.
PR c++/109678
gcc/cp/ChangeLog:
* cp-tree.h (lookup_base): Add offset parm.
* constexpr.cc (cxx_fold_indirect_ref_1): Pass it.
* search.cc (struct lookup_base_data_s): Add offset.
(dfs_lookup_base): Handle it.
(lookup_base): Pass it.
Jason Merrill [Mon, 1 May 2023 21:41:44 +0000 (17:41 -0400)]
c++: std::variant slow to compile [PR109678]
Here, when dealing with a class with a complex subobject structure, we would
try and fail to find the relevant FIELD_DECL for an empty base before giving
up. And we would do this at each level, in a combinatorially problematic
way. Instead, we should check for an empty base first.
PR c++/109678
gcc/cp/ChangeLog:
* constexpr.cc (cxx_fold_indirect_ref_1): Handle empty base first.
Patrick O'Neill [Fri, 7 Apr 2023 20:13:21 +0000 (13:13 -0700)]
RISC-V: Table A.6 conformance tests
These tests cover basic cases to ensure the atomic mappings follow the
strengthened Table A.6 mappings that are compatible with Table A.7.
2023-04-27 Patrick O'Neill <patrick@rivosinc.com>
gcc/testsuite/ChangeLog:
* gcc.target/riscv/amo-table-a-6-amo-add-1.c: New test.
* gcc.target/riscv/amo-table-a-6-amo-add-2.c: New test.
* gcc.target/riscv/amo-table-a-6-amo-add-3.c: New test.
* gcc.target/riscv/amo-table-a-6-amo-add-4.c: New test.
* gcc.target/riscv/amo-table-a-6-amo-add-5.c: New test.
* gcc.target/riscv/amo-table-a-6-compare-exchange-1.c: New test.
* gcc.target/riscv/amo-table-a-6-compare-exchange-2.c: New test.
* gcc.target/riscv/amo-table-a-6-compare-exchange-3.c: New test.
* gcc.target/riscv/amo-table-a-6-compare-exchange-4.c: New test.
* gcc.target/riscv/amo-table-a-6-compare-exchange-5.c: New test.
* gcc.target/riscv/amo-table-a-6-compare-exchange-6.c: New test.
* gcc.target/riscv/amo-table-a-6-compare-exchange-7.c: New test.
* gcc.target/riscv/amo-table-a-6-fence-1.c: New test.
* gcc.target/riscv/amo-table-a-6-fence-2.c: New test.
* gcc.target/riscv/amo-table-a-6-fence-3.c: New test.
* gcc.target/riscv/amo-table-a-6-fence-4.c: New test.
* gcc.target/riscv/amo-table-a-6-fence-5.c: New test.
* gcc.target/riscv/amo-table-a-6-load-1.c: New test.
* gcc.target/riscv/amo-table-a-6-load-2.c: New test.
* gcc.target/riscv/amo-table-a-6-load-3.c: New test.
* gcc.target/riscv/amo-table-a-6-store-1.c: New test.
* gcc.target/riscv/amo-table-a-6-store-2.c: New test.
* gcc.target/riscv/amo-table-a-6-store-compat-3.c: New test.
* gcc.target/riscv/amo-table-a-6-subword-amo-add-1.c: New test.
* gcc.target/riscv/amo-table-a-6-subword-amo-add-2.c: New test.
* gcc.target/riscv/amo-table-a-6-subword-amo-add-3.c: New test.
* gcc.target/riscv/amo-table-a-6-subword-amo-add-4.c: New test.
* gcc.target/riscv/amo-table-a-6-subword-amo-add-5.c: New test.
Signed-off-by: Patrick O'Neill <patrick@rivosinc.com>
Patrick O'Neill [Wed, 5 Apr 2023 16:49:20 +0000 (09:49 -0700)]
RISC-V: Weaken LR/SC pairs
Introduce the %I and %J flags for setting the .aqrl bits on LR/SC pairs
as needed.
Atomic compare and exchange ops provide success and failure memory
models. C++17 and later place no restrictions on the relative strength
of each model, so ensure we cover both by using a model that enforces
the ordering of both given models.
This change brings LR/SC ops in line with table A.6 of the ISA manual.
2023-04-27 Patrick O'Neill <patrick@rivosinc.com>
gcc/ChangeLog:
* config/riscv/riscv-protos.h (riscv_union_memmodels): Expose
riscv_union_memmodels function to sync.md.
* config/riscv/riscv.cc (riscv_union_memmodels): Add function to
get the union of two memmodels in sync.md.
(riscv_print_operand): Add %I and %J flags that output the
optimal LR/SC flag bits for a given memory model.
* config/riscv/sync.md: Remove static .aqrl bits on LR op/.rl
bits on SC op and replace with optimized %I, %J flags.
Signed-off-by: Patrick O'Neill <patrick@rivosinc.com>
Patrick O'Neill [Wed, 5 Apr 2023 16:56:33 +0000 (09:56 -0700)]
RISC-V: Strengthen atomic stores
This change makes atomic stores strictly stronger than table A.6 of the
ISA manual. This mapping makes the overall patchset compatible with
table A.7 as well.
2023-04-27 Patrick O'Neill <patrick@rivosinc.com>
PR target/89835
gcc/ChangeLog:
* config/riscv/sync.md (atomic_store<mode>): Use simple store
instruction in combination with fence(s).
gcc/testsuite/ChangeLog:
* gcc.target/riscv/pr89835.c: New test.
Signed-off-by: Patrick O'Neill <patrick@rivosinc.com>
Patrick O'Neill [Fri, 28 Apr 2023 23:40:27 +0000 (16:40 -0700)]
RISC-V: Name newly added flags in changelog
This patch fixes the changelog to explicitly name the added command line
flags introduced in this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-April/616807.html
2023-05-01 Patrick O'Neill <patrick@rivosinc.com>
Signed-off-by: Patrick O'Neill <patrick@rivosinc.com>
Yanzhang Wang [Wed, 26 Apr 2023 13:06:02 +0000 (21:06 +0800)]
RISC-V: ICE for vlmul_ext_v intrinsic API
PR target/109617
gcc/ChangeLog:
* config/riscv/vector-iterators.md: Support VNx2HI and VNX4DI when MIN_VLEN >= 128.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/vlmul_ext-1.c: New test.
Signed-off-by: Yanzhang Wang <yanzhang.wang@intel.com> Co-authored-by: Pan Li <pan2.li@intel.com> Signed-off-by: Yanzhang Wang <yanzhang.wang@intel.com>
Romain Naour [Tue, 2 May 2023 12:21:55 +0000 (14:21 +0200)]
RISC-V: fix build issue with gcc 4.9.x
GCC should still build with GCC 4.8.3 or newer [1]
using C++03 by default. But a recent change in
RISC-V port introduced a C++11 feature "std::log2" [2].
Use log2 from the C header, without the namespace [3].
Richard Biener [Tue, 2 May 2023 08:34:48 +0000 (10:34 +0200)]
tree-optimization/109672 - properly check emulated plus during vect
The following refactors the check for emulated vector support for
the cases of plus, minus and negate. In the PR we end up with
a SImode plus, supported by the target but emulated and in this
context fail to verify we are dealing with exactly word_mode.
PR tree-optimization/109672
* tree-vect-stmts.cc (vectorizable_operation): For plus,
minus and negate always check the vector mode is word mode.
Richard Biener [Tue, 2 May 2023 09:51:51 +0000 (11:51 +0200)]
[i386] Fix testcases for emulated scatter
The following adjusts testcases where the pr88531 fail with -m32
because we do not consider MMX size vectorization there and the
pr89618 runs into load/store cost differences with -m32.
Jakub Jelinek [Tue, 2 May 2023 08:58:19 +0000 (10:58 +0200)]
ibstdc++: Shut up -Wattribute-alias warning [PR109694]
I've followed what other files do, using attribute alias with not really
matching function type (after all, it isn't really possible when it is a
constructor), but seems I've missed it warns:
../../../../../libstdc++-v3/src/c++98/ios_init.cc:203:8: warning: ‘void std::ios_base_library_init()’ alias between functions of incompatible types ‘void()’ and ‘void
+(std::ios_base::Init::)()’ [-Wattribute-alias=]
203 | void ios_base_library_init (void)
| ^~~~~~~~~~~~~~~~~~~~~
../../../../../libstdc++-v3/src/c++98/ios_init.cc:78:3: note: aliased declaration here
78 | ios_base::Init::Init()
| ^~~~~~~~
The PR talks about clang++ warning there (which I think isn't really
supported, libstdc++ sources ought to be built by GCC), but it warns
when built with GCC too.
The following patch fixes it by doing what other libstdc++ sources do in
those cases.
Marek Polacek [Thu, 9 Mar 2023 23:43:34 +0000 (18:43 -0500)]
ubsan: ubsan_maybe_instrument_array_ref tweak
In <https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613687.html>
we discussed that the copy_node in ubsan_maybe_instrument_array_ref
is redundant, but also that it'd be best to postpone the optimization
to GCC 14. So I'm making that change now.
Jason Merrill [Mon, 1 May 2023 14:57:20 +0000 (10:57 -0400)]
c++: array DMI and member fn [PR109666]
Here it turns out I also needed to adjust cfun when stepping out of the
member function to instantiate the DMI. But instead of adding that tweak,
let's unify with instantiate_body and just push_to_top_level instead of
trying to do the minimum subset of it. There was no measurable change in
compile time on stdc++.h.
This should also resolve 109506 without yet another tweak.
Andrew Pinski [Mon, 1 May 2023 16:21:59 +0000 (09:21 -0700)]
PHIOPT: Update comment about what the pass now does
I noticed I didn't update the comment about how the pass
works after I initially added match_simplify_replacement.
Anyways this updates the comment to be the current state
of the pass.
OK?
gcc/ChangeLog:
* tree-ssa-phiopt.cc: Update comment about
how the transformation are implemented.
Jeff Law [Mon, 1 May 2023 13:40:38 +0000 (07:40 -0600)]
Convert xstormy16 to LRA
This patch converts the xstormy16 patch to LRA. It introduces a code
quality regression in the shiftsi testcase, but it also fixes numerous
aborts/errors. IMHO it's a good tradeoff.
Jeff Law [Mon, 1 May 2023 13:14:50 +0000 (07:14 -0600)]
Enable LRA on several ports
Spurred by Segher's RFC, I went ahead and tested several ports with LRA
enabled. Not surprisingly, many failed, but a few built their full set
of libraries successful and of those a few even ran their testsuites
with no regressions. In fact, enabling LRA fixes a small number of
failures on the iq2000 port.
This patch converts the ports which built their libraries and have test
results that are as good as or better than without LRA. There may
be minor code quality regressions or there may be minor code quality
improvements -- I'm leaving that for the port maintainers to own going
forward.
Rasmus Villemoes [Mon, 13 Feb 2023 15:07:47 +0000 (16:07 +0100)]
apply debug-remap to file names in .su files
The .su files generated with -fstack-usage are arguably debug info. In
order to make builds more reproducible, apply the same remapping logic
to the recorded file names as for when producing the debug info
embedded in the object files.
To this end, teach print_decl_identifier() a new
PRINT_DECL_REMAP_DEBUG flag and use that from output_stack_usage_1().
gcc/ChangeLog:
* print-tree.h (PRINT_DECL_REMAP_DEBUG): New flag.
* print-tree.cc (print_decl_identifier): Implement it.
* toplev.cc (output_stack_usage_1): Use it.
Aldy Hernandez [Thu, 2 Mar 2023 22:37:20 +0000 (23:37 +0100)]
Cleanup irange::set.
Now that anti-ranges are no more and iranges contain wide_ints instead
of trees, various cleanups are possible. This is one of a handful of
patches improving the performance of irange::set() which is not on a
hot path, but quite sensitive because it is so pervasive.
gcc/ChangeLog:
* gimple-range-op.cc (cfn_ffs::fold_range): Use the correct
precision.
* gimple-ssa-warn-alloca.cc (alloca_call_type): Use <2> for
invalid_range, as it is an inverse range.
* tree-vrp.cc (find_case_label_range): Avoid trees.
* value-range.cc (irange::irange_set): Delete.
(irange::irange_set_1bit_anti_range): Delete.
(irange::irange_set_anti_range): Delete.
(irange::set): Cleanup.
* value-range.h (class irange): Remove irange_set,
irange_set_anti_range, irange_set_1bit_anti_range.
(irange::set_undefined): Remove set to m_type.
Aldy Hernandez [Fri, 17 Feb 2023 12:00:47 +0000 (13:00 +0100)]
Rewrite bounds_of_var_in_loop() to use ranges.
Little by little, bounds_of_var_in_loop() has grown into an
unmaintainable mess. This patch rewrites the code to use the relevant
APIs as well as refactor it to make it more readable.
Aldy Hernandez [Thu, 16 Feb 2023 13:25:52 +0000 (14:25 +0100)]
Replace vrp_val* with wide_ints.
This patch removes all uses of vrp_val_{min,max} in favor for a
irange_val_* which are wide_int based. This will leave only one use
of vrp_val_* which returns trees in range_of_ssa_name_with_loop_info()
because it needs to work with non-integers (floats, etc). In a
follow-up patch, this function will also be cleaned up such that
vrp_val_* can be deleted.
The functions min_limit and max_limit in range-op.cc are now useless
as they're basically irange_val*. I didn't rename them yet to avoid
churn. I'll do it in a later patch.
Aldy Hernandez [Thu, 2 Mar 2023 15:34:46 +0000 (16:34 +0100)]
Conversion to irange wide_int API.
This converts the irange API to use wide_ints exclusively, along with
its users.
This patch will slow down VRP, as there will be more useless
wide_int to tree conversions. However, this slowdown is only
temporary, as a follow-up patch will convert the internal
representation of iranges to wide_ints for a net overall gain
in performance.
Aldy Hernandez [Wed, 25 Jan 2023 10:23:33 +0000 (11:23 +0100)]
Various cleanups in vr-values.cc towards ranger API.
gcc/ChangeLog:
* vr-values.cc (check_for_binary_op_overflow): Tidy up by using
ranger API.
(compare_ranges): Delete.
(compare_range_with_value): Delete.
(bounds_of_var_in_loop): Tidy up by using ranger API.
(simplify_using_ranges::fold_cond_with_ops): Cleanup and rename
from vrp_evaluate_conditional_warnv_with_ops_using_ranges.
(simplify_using_ranges::legacy_fold_cond_overflow): Remove
strict_overflow_p and only_ranges.
(simplify_using_ranges::legacy_fold_cond): Adjust call to
legacy_fold_cond_overflow.
(simplify_using_ranges::simplify_abs_using_ranges): Adjust for
rename.
(range_fits_type_p): Rename value_range to irange.
* vr-values.h (range_fits_type_p): Adjust prototype.
Aldy Hernandez [Tue, 24 Jan 2023 12:01:39 +0000 (13:01 +0100)]
vrange_storage overhaul
[tl;dr: This is a rewrite of value-range-storage.* such that global
ranges and the internal ranger cache can use the same efficient
storage mechanism. It is optimized such that when wide_ints are
dropped into irange, the copying back and forth from storage will be
very fast, while being able to hold any number of sub-ranges
dynamically allocated at run-time. This replaces the global storage
mechanism which was limited to 6-subranges.]
Previously we had a vrange allocator for use in the ranger cache. It
worked with trees and could be used in place (fast), but it was not
memory efficient. With the upcoming switch to wide_ints for irange,
we can't afford to allocate ranges that can be used in place, because
an irange will be significantly larger, as it will hold full
wide_ints. We need a trailing_wide_int mechanism similar to what we
use for global ranges, but fast enough to use in the ranger's cache.
The global ranges had another allocation mechanism that was
trailing_wide_int based. It was memory efficient but slow given the
constant conversions from trees to wide_ints.
This patch gets us the best of both worlds by providing a storage
mechanism with a custom trailing wide int interface, while at the same
time being fast enough to use in the ranger cache.
We use a custom trailing wide_int mechanism but more flexible than
trailing_wide_int, since the latter has compile-time fixed-sized
wide_ints. The original TWI structure has the current length of each
wide_int in a static portion preceeding the variable length:
template <int N>
struct GTY((user)) trailing_wide_ints
{
...
...
/* The current length of each number.
that will, in turn, turn off TBAA on gimple, trees and RTL. */
struct {unsigned char len;} m_len[N];
/* The variable-length part of the structure, which always contains
at least one HWI. Element I starts at index I * M_MAX_LEN. */
HOST_WIDE_INT m_val[1];
};
We need both m_len[] and m_val[] to be variable-length at run-time.
In the previous incarnation of the storage mechanism the limitation of
m_len[] being static meant that we were limited to whatever [N] could
use up the unused bits in the TWI control world. In practice this
meant we were limited to 6 sub-ranges. This worked fine for global
ranges, but is a no go for our internal cache, where we must represent
things exactly (ranges for switches, etc).
The new implementation removes this restriction by making both m_len[]
and m_val[] variable length. Also, rolling our own allows future
optimization be using some of the leftover bits in the control world.
Also, in preparation for the wide_int conversion, vrange_storage is
now optimized to blast the bits directly into the ultimate irange
instead of going through the irange API. So ultimately copying back
and forth between the ranger cache and the storage mechanism is just a
matter of copying a few bits for the control word, and copying an
array of HOST_WIDE_INTs. These changes were heavily profiled, and
yielded a good chunk of the overall speedup for the wide_int
conversion.
Finally, vrange_storage is now a first class structure with GTY
markers and all, thus alleviating the void * hack in struct
tree_ssa_name and friends. This removes a few warts in the API and
looks cleaner overall.
Roger Sayle [Sun, 30 Apr 2023 22:47:13 +0000 (23:47 +0100)]
[Committed] Update xstormy16's neghi2 pattern to not clobber the carry flag.
When I converted xstormy's neghi2 pattern from a define_expand to a
define_insn, I forgot that define_expand implicitly produces a
sequence of instructions, but a define_insn is an implicit parallel,
thereby messing up the clobber (reg:BI CARRY_REG), which can then cause
an ICE in the auto-generated added_clobbers_hard_reg_p. Whilst stripping
the superfluous PARALLEL resolves this issue, an even better fix is to
use xstormy16's INC instruction, that (like NOT) doesn't affect the carry
flag, resulting in a neghi2 implementation that can more easily be CSE'd
and scheduled.
Many thanks (again) to Jeff Law for testing/reporting this issue.
2024-04-30 Roger Sayle <roger@nextmovesoftware.com>
gcc/ChangeLog
* config/stormy16/stormy16.md (neghi2): Rewrite pattern using
inc to avoid clobbering the carry flag.
Andrew Pinski [Wed, 30 Nov 2022 04:02:07 +0000 (04:02 +0000)]
Improve error message for excess elements in array initializer from {"a"}
So char arrays are not the only type that be initialized from {"a"}.
We can have wchar_t (L"") and char16_t (u"") types too. So let's
print out the type of the array instead of just saying char.
Note in the testsuite I used regex . to match '[' and ']' as
I could not figure out how many '\' I needed.
OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
gcc/c/ChangeLog:
* c-typeck.cc (process_init_element): Print out array type
for excessive elements.
Andrew Pinski [Wed, 30 Nov 2022 02:54:57 +0000 (02:54 +0000)]
Fix C/107926: Wrong error message when initializing char array
The problem here is the code which handles {"a"} is supposed
to handle the case where the is something after the string but
it only handles the case where there is another string so
we go down the other path and error out saying "excess elements
in struct initializer" even though this was a character array.
To fix this, we need to move the ckeck if the initializer is
a string after the check for array and initializer.
OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
Thanks,
Adnrew Pinski
gcc/c/ChangeLog:
PR c/107926
* c-typeck.cc (process_init_element): Move the check
for string cst until after the error message.
Andrew Pinski [Sun, 9 Apr 2023 01:46:37 +0000 (18:46 -0700)]
MATCH: add some of what phiopt's builtin_zero_pattern did
This adds the patterns for
POPCOUNT BSWAP FFS PARITY CLZ and CTZ.
For "a != 0 ? FUNC(a) : CST".
CLRSB, CLRSBL, and CLRSBLL will be moved next.
Note this is not enough to remove
cond_removal_in_builtin_zero_pattern as we need to handle
the case where there is an NOP_CONVERT inside the conditional
to move out of the condition inside match_simplify_replacement.
OK? Bootstrapped and tested on x86_64-linux-gnu.
gcc/ChangeLog:
* match.pd: Add patterns for "a != 0 ? FUNC(a) : CST"
for FUNC of POPCOUNT BSWAP FFS PARITY CLZ and CTZ.
git://gcc.gnu.org / gcc.git / log