Nathan Myers [Thu, 21 Aug 2025 00:24:29 +0000 (20:24 -0400)]
libstdc++: Move tai_- and gps_clock::now impls out of ABI
This patch moves std::tai_clock::now() and std::tai_clock::now()
definitions from header inlines to static members invoked via a
normal function call, in service of stabilizing the C++20 ABI.
It also changes #if guards to mention the actual __cpp_lib_*
feature gated, not just the language version, for clarity.
New global function symbols std::chrono::tai_clock::now
and std::chrono::gps_clock::now are exported.
Tomasz Kamiński [Tue, 26 Aug 2025 12:34:35 +0000 (14:34 +0200)]
libsupc++: Change _Unordered comparison value to minimum value of signed char.
For any minimum value of a signed type, its negation (with wraparound) results
in the same value, behaving like zero. Representing the unordered result with
this minimum value, along with 0 for equal, 1 for greater, and -1 for less
in partial_ordering, allows its value to be reversed using unary negation.
The operator<=(partial_order, 0) now checks if the reversed value is positive.
This works correctly because the unordered value remains unchanged and thus
negative.
libstdc++-v3/ChangeLog:
* libsupc++/compare (_Ncmp::_Unordered): Rename and change the value
to minimum value of signed char.
(_Ncomp::unordered): Renamed from _Unordered, the name is reserved
by partial_ordered::unordered.
(partial_ordering::_M_reverse()): Define.
(operator<=(partial_ordering, __cmp_cat::__unspec))
(operator>=(__cmp_cat::__unspec, partial_ordering)): Implemented
in terms of negated _M_value.
(operator>=(partial_ordering, __cmp_cat::__unspec))
(operator<=(__cmp_cat::__unspec, partial_ordering)): Directly
compare _M_value, as unordered value is negative.
(partial_ordering::unordered): Handle _Ncmp::unoredred rename.
* python/libstdcxx/v6/printers.py: Add -128 as integer value
for unordered, keeping 2 to preserve backward compatibility.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com> Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
Jakub Jelinek [Wed, 27 Aug 2025 12:00:51 +0000 (14:00 +0200)]
c++: Fix up cpp_warn on __STDCPP_FLOAT*_T__ [PR121520]
I got the cpp_warn on __STDCPP_FLOAT*_T__ if we aren't predefining those
wrong, so e.g. on powerpc64le we don't diagnose #undef __STDCPP_FLOAT16_T__.
I've added it as else if on the
if (c_dialect_cxx () && cxx_dialect > cxx20 && !floatn_nx_types[i].extended)
condition, which means cpp_warn is called in case a target supports some
extended type like _Float32x, cpp_warn is called on __STDCPP_FLOAT32_T__
(where when it supported _Float32 as well it did cpp_define_warn
(pfile, "__STDCPP_FLOAT32_T__=1") earlier).
On targets where the types aren't supported the earlier
if (FLOATN_NX_TYPE_NODE (i) == NULL_TREE) continue;
path is taken.
This patch fixes it to cpp_warn on the non-extended types for C++23
if the target doesn't support them and cpp_define_warn as before if it does.
2025-08-27 Jakub Jelinek <jakub@redhat.com>
PR target/121520
* c-cppbuiltin.cc (c_cpp_builtins): Properly call cpp_warn
for __STDCPP_FLOAT<NN>_T__ if FLOATN_NX_TYPE_NODE (i) is NULL
for C++23 for non-extended types and don't call cpp_warn for
extended types.
Richard Biener [Wed, 27 Aug 2025 07:53:49 +0000 (09:53 +0200)]
tree-optimization/121686 - failed SLP discovery for live recurrence
The following adjusts the SLP build for only-live stmts to not
only consider vect_induction_def and vect_internal_def that are
not part of a reduction but instead consider all non-reduction
defs that are not part of a reduction, specifically in this case
a recurrence def. This is also a missed optimization on the
gcc-15 branch (but IMO a very minor one).
PR tree-optimization/121686
* tree-vect-slp.cc (vect_analyze_slp): Consider all only-live
non-reduction defs for discovery.
Andrew Pinski [Wed, 27 Aug 2025 03:57:09 +0000 (20:57 -0700)]
testsuite; Fix unprotected-allocas-1.c at -O3 [PR121684]
The problem here is after r16-101, the 2 functions containing alloca/VLA
start to be cloned and then we un-VLA happens in using_vararray so this
is no longer testing what it should be testing.
The obvious fix is to mark using_vararray and using_alloca as noclone too.
Pushed as obvious after a quick test to make sure it is now working.
gcc/testsuite/ChangeLog:
PR testsuite/121684
* c-c++-common/hwasan/unprotected-allocas-0.c: Mark
using_vararray and using_alloca as noclone too.
Signed-off-by: Andrew Pinski <andrew.pinski@oss.qualcomm.com>
Tomasz Kamiński [Tue, 19 Aug 2025 14:44:49 +0000 (16:44 +0200)]
libstdc++: Reduce chances of object aliasing for function wrapper.
Previously, an empty functor (EmptyIdFunc) stored inside a
std::move_only_function being first member of a Composite class could have the
same address as the base of the EmptyIdFunc type (see included test cases),
resulting in two objects of the same type at the same address.
This commit addresses the issue by moving the internal buffer from the start
of the wrapper object to a position after the manager function pointer. This
minimizes aliasing with the stored buffer but doesn't completely eliminate it,
especially when multiple empty base objects are involved (PR121180).
To facilitate this member reordering, the private section of _Mo_base was
eliminated, and the corresponding _M_manager and _M_destroy members were made
protected. They remain inaccessible to users, as user-facing wrappers derive
from _Mo_base privately.
libstdc++-v3/ChangeLog:
* include/bits/funcwrap.h (__polyfunc::_Mo_base): Reorder _M_manage
and _M_storage members. Make _M_destroy protected and remove friend
declaration.
* testsuite/20_util/copyable_function/call.cc: Add test for aliasing
base class.
* testsuite/20_util/move_only_function/call.cc: Likewise.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com> Reviewed-by: Patrick Palka <ppalka@redhat.com> Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
Jeff Law [Wed, 27 Aug 2025 00:57:01 +0000 (18:57 -0600)]
More RISC-V testsuite hygiene
More testsuite hygiene. Some of the thead tests are expecting to find
xtheadvdot in the extension set, but it's not defined as a valid extension
anywhere. I'm just removing xtheadvdot. Someone more familiar with these
cores can add it back properly if they're so inclined.
Second, there's a space after the zifencei in a couple of the thead arch
strings. Naturally that causes failures as well. That's a trivial fix, just
remove the bogus whitespace.
That gets us clean on riscv.exp on the pioneer system.
The pioneer is happy, as is riscv32-elf and riscv64-elf. Pushing to the trunk.
gcc/
* config/riscv/riscv-cores.def (xt-c908v): Drop xtheadvdot.
(xt-c910v2): Remove extraenous whitespace.
(xt-c920v2): Drop xtheadvdot and remove extraeonous whitespace.
gcc/testsuite/
* gcc.target/riscv/mcpu-xt-c908v.c: Drop xtheadvdot.
* gcc.target/riscv/mcpu-xt-c920v2.c: Drop xtheadvdot.
Sandra Loosemore [Mon, 25 Aug 2025 01:43:50 +0000 (01:43 +0000)]
OpenMP: give error when variant is the same as the base function [PR118839]
As noted in the issue, the C++ front end has deeper problems: it's
supposed to do the name lookup of the variant at the call site but is
instead doing it when parsing the "declare variant" construct, before
registering the decl for the base function. The C++ part of the
patch is a band-aid to catch the case where there is a previous declaration
of the function and it doesn't give an undefined symbol error instead.
Some real solution ought to be included as part of fixing PR118791.
gcc/c/
PR middle-end/118839
* c-parser.cc (c_finish_omp_declare_variant): Error if variant
is the same as base.
gcc/cp/
PR middle-end/118839
* decl.cc (omp_declare_variant_finalize_one): Error if variant
is the same as base.
gcc/fortran/
PR middle-end/118839
* trans-openmp.cc (gfc_trans_omp_declare_variant): Error if variant
is the same as base.
Sandra Loosemore [Mon, 25 Aug 2025 01:43:49 +0000 (01:43 +0000)]
OpenMP: Improve front-end error-checking for "declare variant"
This patch fixes a number of problems with parser error checking of
"declare variant", especially in the C front end.
The new C testcase unprototyped-variant.c added by this patch used to
ICE when gimplifying the call site, at least in part because the
variant was being recorded even after it was diagnosed as invalid.
There was also a large block of dead code in the C front end that was
supposed to fix up an unprototyped declaration of a variant function
to match the base function declaration, that was never executed because
it was nested in a conditional that could never be true. I've fixed those
problems by rearranging the code and only recording the variant if it
passes the correctness checks. I also tried to add some comments and
re-work some particularly confusing bits of code, so that it's easier to
understand.
The OpenMP specification doesn't say what the behavior of "declare
variant" with the "append_args" clause should be when the base
function is unprototyped. The additional arguments are supposed to be
inserted between the last fixed argument of the base function and any
varargs, but without a prototype, for any given call we have no idea
which arguments are fixed and which are varargs, and therefore no idea
where to insert the additional arguments. This used to trigger some
other diagnostics (which one depending on whether the variant was also
unprototyped), but I thought it was better to just reject this with an
explicit "sorry".
Finally, I also observed that a missing "match" clause was only
rejected if "append_args" or "adjust_args" was present. Per the spec,
"match" has the "required" property, so if it's missing it should be
diagnosed unconditionally. The C++ and Fortran front ends had the same
issue so I fixed this one there too.
gcc/c/ChangeLog
* c-parser.cc (c_finish_omp_declare_variant): Rework diagnostic
code. Do not record variant if there are errors. Make check for
a missing "match" clause unconditional.
gcc/cp/ChangeLog
* parser.cc (cp_finish_omp_declare_variant): Structure diagnostic
code similarly to C front end. Make check for a missing "match"
clause unconditional.
gcc/fortran/ChangeLog
* openmp.cc (gfc_match_omp_declare_variant): Make check for a
missing "match" clause unconditional.
Jeff Law [Tue, 26 Aug 2025 22:50:02 +0000 (16:50 -0600)]
[committed] RISC-V Testsuite hygiene
Shreya and I were working through some testsuite failures and noticed that many
of the current failures on the pioneer were just silly. We have tests that
expect to see full architecture strings in their expected output when the bulk
(some might say all) of the architecture string is irrelevant.
Worse yet, we'd have different matching lines. ie we'd have one that would
machine rv64gc_blah_blah and another for rv64imfa_blah_blah. Judicious
wildcard usage cleans this up considerably.
This fixes ~80 failures in the riscv.exp testsuite. Pushing to the trunk as
it's happy on the pioneer native, riscv32-elf and riscv64-elf.
gcc/testsuite/
* gcc.target/riscv/arch-25.c: Use wildcards to simplify/eliminate
dg-error directives.
* gcc.target/riscv/arch-ss-2.c: Similarly.
* gcc.target/riscv/arch-zilsd-2.c: Similarly.
* gcc.target/riscv/arch-zilsd-3.c: Similarly.
Patrick Palka [Tue, 26 Aug 2025 19:45:57 +0000 (15:45 -0400)]
libstdc++/ranges: Prefer using offset-based _CachedPosition
The offset-based partial specialization of _CachedPosition for
random-access iterators is currently only selected if the offset type is
smaller than the iterator type. Before r12-1018-g46ed811bcb4b86 this
made sense since the main partial specialization only stored the
iterator (incorrectly). After that bugfix, the main partial
specialization now effectively stores a std::optional<iter> so the
size constraint is inaccurate. And this main partial specialization
must invalidate itself upon copy/move unlike the offset-based partial
specialization. So I think we should just always prefer the
offset-based _CachedPosition for a random-access iterator, even if the
offset type happens to be larger than the iterator type.
libstdc++-v3/ChangeLog:
* include/std/ranges (__detail::_CachedPosition): Remove
additional size constraint on the offset-based partial
specialization.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com> Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
David Faust [Tue, 26 Aug 2025 19:14:15 +0000 (12:14 -0700)]
testsuite: restrict ctf-array-7 test to 64-bit targets [PR121411]
The test fails to compile on 32-bit targets because the arrays are too
large. Restrict to targets where the array index type is 64-bits.
Also note the relevant PR in the test comment.
PR debug/121411
gcc/testsuite/
* gcc.dg/debug/ctf/ctf-array-7.c: Restrict to lp64,llp64
targets.
Tomasz Kamiński [Mon, 25 Aug 2025 11:15:35 +0000 (13:15 +0200)]
libstdc++: Do not require assignment for vector::resize(n, v) [PR90192]
This patch introduces a new function, _M_fill_append, which is invoked when
copies of the same value are appended to the end of a vector. Unlike
_M_fill_insert(end(), n, v), _M_fill_append never permute elements in place,
so it does not require:
* vector element type to be assignable;
* a copy of the inserted value, in the case where it points to an
element of the vector.
vector::resize(n, v) now uses _M_fill_append, fixing the non-conformance where
element types were required to be assignable.
In addition, _M_fill_insert(end(), n, v) now delegates to _M_fill_append, which
eliminates an unnecessary copy of v when the existing capacity is used.
PR libstdc++/90192
libstdc++-v3/ChangeLog:
* include/bits/stl_vector.h (vector<T>::_M_fill_append): Declare.
(vector<T>::fill): Use _M_fill_append instead of _M_fill_insert.
* include/bits/vector.tcc (vector<T>::_M_fill_append): Define
(vector<T>::_M_fill_insert): Delegate to _M_fill_append when
elements are appended.
* testsuite/23_containers/vector/modifiers/moveable.cc: Updated
copycount for inserting at the end (appending).
* testsuite/23_containers/vector/modifiers/resize.cc: New test.
* testsuite/backward/hash_set/check_construct_destroy.cc: Updated
copycount, the hash_set constructor uses insert to fill buckets
with nullptrs.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com> Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
Tomasz Kamiński [Tue, 19 Aug 2025 13:32:47 +0000 (15:32 +0200)]
libstdc++: Refactor bound arguments storage for bind_front/back
This patch refactors the implementation of bind_front and bind_back to avoid
using std::tuple for argument storage. Instead, bound arguments are now:
* stored directly if there is only one,
* within a dedicated _Bound_arg_storage otherwise.
_Bound_arg_storage is less expensive to instantiate and access than std::tuple.
It can also be trivially copyable, as it doesn't require a non-trivial assignment
operator for reference types. Storing a single argument directly provides similar
benefits compared to both one element tuple or _Bound_arg_storage.
_Bound_arg_storage holds each argument in an _Indexed_bound_arg base object.
The base class is parameterized by both type and index to allow storing
multiple arguments of the same type. Invocations are handled by _S_apply_front
amd _S_apply_back static functions, which simulate explicit object parameters.
To facilitate this, the __like_t alias template is now unconditionally available
since C++11 in bits/move.h.
libstdc++-v3/ChangeLog:
* include/bits/move.h (std::__like_impl, std::__like_t): Make
available in c++11.
* include/std/functional (std::_Indexed_bound_arg)
(std::_Bound_arg_storage, std::__make_bound_args): Define.
(std::_Bind_front, std::_Bind_back): Use _Bound_arg_storage.
* testsuite/20_util/function_objects/bind_back/1.cc: Expand
test to cover cases of 0, 1, many bound args.
* testsuite/20_util/function_objects/bind_back/111327.cc: Likewise.
* testsuite/20_util/function_objects/bind_front/1.cc: Likewise.
* testsuite/20_util/function_objects/bind_front/111327.cc: Likewise.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com> Reviewed-by: Patrick Palka <ppalka@redhat.com> Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
Tomasz Kamiński [Thu, 21 Aug 2025 16:00:25 +0000 (18:00 +0200)]
libstdc++: Specialize _Never_valueless_alt for jthread, stop_token and stop_source
The move constructors for stop_source and stop_token are equivalent to
copying and clearing the raw pointer, as they are wrappers for a
counted-shared state.
For jthread, the move constructor performs a member-wise move of stop_source
and thread. While std::thread could also have a _Never_valueless_alt
specialization due to its inexpensive move (only moving a handle), doing
so now would change the ABI. This patch takes the opportunity to correct
this behavior for jthread, before C++20 API is marked stable.
Enable unroll in the vectorizer when there's reduction for FMA/DOT_PROD_EXPR/SAD_EXPR
The patch is trying to unroll the vectorized loop when there're
FMA/DOT_PRDO_EXPR/SAD_EXPR reductions, it will break cross-iteration dependence
and enable more parallelism(since vectorize will also enable partial
sum).
When there's gather/scatter or scalarization in the loop, don't do the
unroll since the performance bottleneck is not at the reduction.
The unroll factor is set according to FMA/DOT_PROX_EXPR/SAD_EXPR
CEIL ((latency * throught), num_of_reduction)
.i.e
For fma, latency is 4, throught is 2, if there's 1 FMA for reduction
then unroll factor is 2 * 4 / 1 = 8.
There's also a vect_unroll_limit, the final suggested_unroll_factor is
set as MIN (vect_unroll_limix, 8).
The vect_unroll_limit is mainly for register pressure, avoid to many
spills.
Ideally, all instructions in the vectorized loop should be used to
determine unroll_factor with their (latency * throughput) / number,
but that would too much for this patch, and may just GIGO, so the
patch only considers 3 kinds of instructions: FMA, DOT_PROD_EXPR,
SAD_EXPR.
Note when DOT_PROD_EXPR is not native support,
m_num_reduction += 3 * count which almost prevents unroll.
There's performance boost for simple benchmark with DOT_PRDO_EXPR/FMA
chain, slight improvement in SPEC2017 performance.
gcc/ChangeLog:
* config/i386/i386.cc (ix86_vector_costs::ix86_vector_costs):
Addd new memeber m_num_reduc, m_prefer_unroll.
(ix86_vector_costs::add_stmt_cost): Set m_prefer_unroll and
m_num_reduc
(ix86_vector_costs::finish_cost): Determine
m_suggested_unroll_vector with consideration of
reduc_lat_mult_thr, m_num_reduction and
ix86_vect_unroll_limit.
* config/i386/i386.h (enum ix86_reduc_unroll_factor): New
enum.
(processor_costs): Add reduc_lat_mult_thr and
vect_unroll_limit.
* config/i386/x86-tune-costs.h: Initialize
reduc_lat_mult_thr and vect_unroll_limit.
* config/i386/i386.opt: Add -param=ix86-vect-unroll-limit.
gcc/testsuite/ChangeLog:
* gcc.target/i386/vect_unroll-1.c: New test.
* gcc.target/i386/vect_unroll-2.c: New test.
* gcc.target/i386/vect_unroll-3.c: New test.
* gcc.target/i386/vect_unroll-4.c: New test.
* gcc.target/i386/vect_unroll-5.c: New test.
[PATCH] RISC-V: Add pattern for reverse floating-point divide
This pattern enables the combine pass (or late-combine, depending on the case)
to merge a vec_duplicate into a div RTL instruction. The vec_duplicate is the
dividend operand.
Before this patch, we have two instructions, e.g.:
vfmv.v.f v2,fa0
vfdiv.vv v1,v2,v1
After, we get only one:
vfrdiv.vf v1,v1,fa0
gcc/ChangeLog:
* config/riscv/autovec-opt.md (*vfrdiv_vf_<mode>): Add new pattern to
combine vec_duplicate + vfdiv.vv into vfrdiv.vf.
* config/riscv/vector.md (@pred_<optab><mode>_reverse_scalar): Allow VLS
modes.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/vx_vf/vf-1-f16.c: Add vfrdiv.
* gcc.target/riscv/rvv/autovec/vx_vf/vf-1-f32.c: Likewise.
* gcc.target/riscv/rvv/autovec/vx_vf/vf-1-f64.c: Likewise.
* gcc.target/riscv/rvv/autovec/vx_vf/vf-2-f16.c: Likewise.
* gcc.target/riscv/rvv/autovec/vx_vf/vf-2-f32.c: Likewise.
* gcc.target/riscv/rvv/autovec/vx_vf/vf-2-f64.c: Likewise.
* gcc.target/riscv/rvv/autovec/vx_vf/vf-3-f16.c: Likewise.
* gcc.target/riscv/rvv/autovec/vx_vf/vf-3-f32.c: Likewise.
* gcc.target/riscv/rvv/autovec/vx_vf/vf-3-f64.c: Likewise.
* gcc.target/riscv/rvv/autovec/vx_vf/vf-4-f16.c: Likewise.
* gcc.target/riscv/rvv/autovec/vx_vf/vf-4-f32.c: Likewise.
* gcc.target/riscv/rvv/autovec/vx_vf/vf-4-f64.c: Likewise.
* gcc.target/riscv/rvv/autovec/vx_vf/vf_binop.h: Add support for reverse
variants.
* gcc.target/riscv/rvv/autovec/vx_vf/vf_binop_data.h: Add data for
reverse variants.
* gcc.target/riscv/rvv/autovec/vx_vf/vf_vfrdiv-run-1-f16.c: New test.
* gcc.target/riscv/rvv/autovec/vx_vf/vf_vfrdiv-run-1-f32.c: New test.
* gcc.target/riscv/rvv/autovec/vx_vf/vf_vfrdiv-run-1-f64.c: New test.
Tamar Christina [Tue, 26 Aug 2025 12:10:10 +0000 (13:10 +0100)]
AArch64: extend cost model to cost outer loop vect where the inner loop is invariant [PR121290]
Consider the example:
void
f (int *restrict x, int *restrict y, int *restrict z, int n)
{
for (int i = 0; i < 4; ++i)
{
int res = 0;
for (int j = 0; j < 100; ++j)
res += y[j] * z[i];
x[i] = res;
}
}
which is not useful because by doing outer-loop vectorization we're performing
less work per iteration than we would had we done inner-loop vectorization and
simply unrolled the inner loop.
This patch teaches the cost model that if all your leafs are invariant, then
adjust the loop cost by * VF, since every vector iteration has at least one lane
really just doing 1 scalar.
There are a couple of ways we could have solved this, one is to increase the
unroll factor to process more iterations of the inner loop. This removes the
need for the broadcast, however we don't support unrolling the inner loop within
the outer loop. We only support unrolling by increasing the VF, which would
affect the outer loop as well as the inner loop.
We also don't directly support costing inner-loop vs outer-loop vectorization,
and as such we're left trying to predict/steer the cost model ahead of time to
what we think should be profitable. This patch attempts to do so using a
heuristic which penalizes the outer-loop vectorization.
We now cost the loop as
note: Cost model analysis:
Vector inside of loop cost: 2000
Vector prologue cost: 4
Vector epilogue cost: 0
Scalar iteration cost: 300
Scalar outside cost: 0
Vector outside cost: 4
prologue iterations: 0
epilogue iterations: 0
missed: cost model: the vector iteration cost = 2000 divided by the scalar iteration cost = 300 is greater or equal to the vectorization factor = 4.
missed: not vectorized: vectorization not profitable.
missed: not vectorized: vector version will never be profitable.
missed: Loop costings may not be worthwhile.
Jeff Law [Tue, 26 Aug 2025 12:10:00 +0000 (06:10 -0600)]
Fix RISC-V bootstrap
Recent changes from Kito have an unused parameter. On the assumption that he's
going to likely want it as part of the API, I've simply removed the parameter's
name until such time as Kito needs it.
This should restore bootstrapping to the RISC-V port. Committing now rather
than waiting for the CI system given bootstrap builds currently fail.
* config/riscv/riscv.cc (riscv_arg_partial_bytes): Remove name
from unused parameter.
Richard Earnshaw [Tue, 26 Aug 2025 10:55:29 +0000 (11:55 +0100)]
arm: testsuite: make gcc.target/arm/bics_3.c generate bics again
The compiler is getting too smart! But this test is really intended
to test that we generate BICS instead of BIC+CMP, so make the test use
something that we can't subsequently fold away into a bit minipulation
of a store-flag value.
I've also added a couple of extra tests, so we now cover both the
cases where we fold the result away and where that cannot be done.
Also add a test that we don't generate a compare against 0, since
that's really part of what this test is covering.
gcc/testsuite:
* gcc.target/arm/bics_3.c: Add some additional tests that
cannot be folded to a bit manipulation.
Richard Biener [Tue, 26 Aug 2025 07:04:36 +0000 (09:04 +0200)]
Compute vect_reduc_type off SLP node instead of stmt-info
The following changes the vect_reduc_type API to work on the SLP node.
The API is only used from the aarch64 backend, so all changes are there.
In particular I noticed aarch64_force_single_cycle is invoked even
for scalar costing (where the flag tested isn't computed yet), I
figured in scalar costing all reductions are a single cycle.
* tree-vectorizer.h (vect_reduc_type): Get SLP node as argument.
* config/aarch64/aarch64.cc (aarch64_sve_in_loop_reduction_latency):
Take SLO node as argument and adjust.
(aarch64_in_loop_reduction_latency): Likewise.
(aarch64_detect_vector_stmt_subtype): Adjust.
(aarch64_vector_costs::count_ops): Likewise. Treat reductions
during scalar costing as single-cycle.
Richard Biener [Tue, 26 Aug 2025 08:34:01 +0000 (10:34 +0200)]
tree-optimization/121659 - bogus swap of reduction operands
The following addresses a bogus swapping of SLP operands of a
reduction operation which gets STMT_VINFO_REDUC_IDX out of sync
with the SLP operand order. In fact the most obvious mistake is
that we simply swap operands even on the first stmt even when
there's no difference in the comparison operators (for == and !=
at least). But there are more latent issues that I noticed and
fixed up in the process.
PR tree-optimization/121659
* tree-vect-slp.cc (vect_build_slp_tree_1): Do not allow
matching up comparison operators by swapping if that would
disturb STMT_VINFO_REDUC_IDX. Make sure to only
actually mark operands for swapping when there was a
mismatch and we're not processing the first stmt.
Richard Biener [Mon, 25 Aug 2025 12:40:27 +0000 (14:40 +0200)]
Remove STMT_VINFO_REDUC_VECTYPE_IN
This was added when invariants/externals outside of SLP didn't have
an easily accessible vector type. Now it's redundant so the
following removes it.
* tree-vectorizer.h (stmt_vec_info_::reduc_vectype_in): Remove.
(STMT_VINFO_REDUC_VECTYPE_IN): Likewise.
* tree-vect-loop.cc (vect_is_emulated_mixed_dot_prod): Get
at the input vectype via the SLP node child.
(vectorizable_lane_reducing): Likewise.
(vect_transform_reduction): Likewise.
(vectorizable_reduction): Do not set STMT_VINFO_REDUC_VECTYPE_IN.
Jakub Jelinek [Tue, 26 Aug 2025 04:43:39 +0000 (06:43 +0200)]
i386: Fix up recent changes to use GFNI for rotates/shifts [PR121658]
The vgf2p8affineqb_<mode><mask_name> pattern uses "register_operand"
predicate for the first input operand, so using "general_operand"
for the rotate operand passed to it leads to ICEs, and so does
the "nonimmediate_operand" in the <insn>v16qi3 define_expand.
The following patch fixes it by using "register_operand" in the former
case (that pattern is TARGET_GFNI only) and using force_reg in
the latter case (the pattern is TARGET_XOP || TARGET_GFNI and for XOP
we can handle MEM operand).
The rest of the changes are small formatting tweaks or use of const0_rtx
instead of GEN_INT (0).
2025-08-26 Jakub Jelinek <jakub@redhat.com>
PR target/121658
* config/i386/sse.md (<insn><mode>3 any_shift): Use const0_rtx
instead of GEN_INT (0).
(cond_<insn><mode> any_shift): Likewise. Formatting fix.
(<insn><mode>3 any_rotate): Use register_operand predicate instead of
general_operand for match_operand 1. Use const0_rtx instead of
GEN_INT (0).
(<insn>v16qi3 any_rotate): Use force_reg on operands[1]. Formatting
fix.
* config/i386/i386.cc (ix86_shift_rotate_cost): Comment formatting
fixes.
Pan Li [Sat, 23 Aug 2025 04:55:50 +0000 (12:55 +0800)]
RISC-V: Combine vec_duplicate + vmacc.vv to vmacc.vx on GR2VR cost
This patch would like to combine the vec_duplicate + vmacc.vv to the
vmacc.vx. From example as below code. The related pattern will depend
on the cost of vec_duplicate from GR2VR. Then the late-combine will
take action if the cost of GR2VR is zero, and reject the combination
if the GR2VR cost is greater than zero.
Assume we have example code like below, GR2VR cost is 0.
#define DEF_VX_TERNARY_CASE_0(T, OP_1, OP_2, NAME) \
void \
test_vx_ternary_##NAME##_##T##_case_0 (T * restrict vd, T * restrict vs2, \
T rs1, unsigned n) \
{ \
for (unsigned i = 0; i < n; i++) \
vd[i] = vd[i] OP_2 vs2[i] OP_1 rs1; \
}
* config/riscv/vector.md (@pred_mul_plus_vx_<mode>): Add new pattern to
generate vmacc rtl.
(*pred_macc_<mode>_scalar_undef): Ditto.
* config/riscv/autovec-opt.md (*vmacc_vx_<mode>): Add new
pattern to match the vmacc vx combine.
Jakub Jelinek [Mon, 25 Aug 2025 22:28:10 +0000 (00:28 +0200)]
omp-expand: Initialize fd->loop.n2 if needed for the zero iter case [PR121453]
When expand_omp_for_init_counts is called from expand_omp_for_generic,
zero_iter1_bb is NULL and the code always creates a new bb in which it
clears fd->loop.n2 var (if it is a var), because it can dominate code
with lastprivate guards that use the var.
When called from other places, zero_iter1_bb is non-NULL and so we don't
insert the clearing (and can't, because the same bb is used also for the
non-zero iterations exit and in that case we need to preserve the iteration
count). Clearing is also not necessary when e.g. outermost collapsed
loop has constant non-zero number of iterations, in that case we initialize the
var to something already earlier. The following patch makes sure to clear
it if it hasn't been initialized yet before the first check for zero iterations.
2025-08-26 Jakub Jelinek <jakub@redhat.com>
PR middle-end/121453
* omp-expand.cc (expand_omp_for_init_counts): Clear fd->loop.n2
before first zero count check if zero_iter1_bb is non-NULL upon
entry and fd->loop.n2 has not been written yet.
David Faust [Wed, 6 Aug 2025 16:24:40 +0000 (09:24 -0700)]
ctf: avoid overflow for array num elements [PR121411]
CTF array encoding uses uint32 for number of elements. This means there
is a hard upper limit on array types which the format can represent.
GCC internally was also using a uint32_t for this, which would overflow
when translating from DWARF for arrays with more than UINT32_MAX
elements. Use an unsigned HOST_WIDE_INT instead to fetch the array
bound, and fall back to CTF_K_UNKNOWN if the array cannot be
represented in CTF.
PR debug/121411
gcc/
* dwarf2ctf.cc (gen_ctf_subrange_type): Use unsigned HWI for
array_num_elements. Fallback to CTF_K_UNKNOWN if the array
type has too many elements for CTF to represent.
After changing the return type of remove_prop_source_from_use,
forward_propagate_into_comparison will never return 2. So boolify
forward_propagate_into_comparison.
Bootstrapped and tested on x86_64-linux-gnu.
gcc/ChangeLog:
* tree-ssa-forwprop.cc (forward_propagate_into_comparison): Boolify.
(pass_forwprop::execute): Don't handle return of 2 from
forward_propagate_into_comparison.
Signed-off-by: Andrew Pinski <andrew.pinski@oss.qualcomm.com>
Andrew Pinski [Sun, 24 Aug 2025 20:33:21 +0000 (13:33 -0700)]
forwprop: Remove return type of remove_prop_source_from_use
Since r5-4705-ga499aac5dfa5d9, remove_prop_source_from_use has always
return false. This removes the return type of remove_prop_source_from_use
and cleans up the usage of remove_prop_source_from_use.
Bootstrapped and tested on x86_64-linux-gnu.
gcc/ChangeLog:
* tree-ssa-forwprop.cc (remove_prop_source_from_use): Remove
return type.
(forward_propagate_into_comparison): Update dealing with
no return type of remove_prop_source_from_use.
(forward_propagate_into_gimple_cond): Likewise.
(simplify_permutation): Likewise.
Signed-off-by: Andrew Pinski <andrew.pinski@oss.qualcomm.com>
Andrew Pinski [Sun, 24 Aug 2025 06:47:22 +0000 (23:47 -0700)]
forwprop: Mark the old switch index for (maybe) dceing
While looking at this code I noticed that we don't remove
the old switch index assignment if it is only used in the switch
after it is modified in simplify_gimple_switch.
This fixes that by marking the old switch index for the dce worklist.
Bootstrapped and tested on x86_64-linux-gnu.
gcc/ChangeLog:
* tree-ssa-forwprop.cc (simplify_gimple_switch): Add simple_dce_worklist
argument. Mark the old index when doing the replacement.
(pass_forwprop::execute): Update call to simplify_gimple_switch.
Signed-off-by: Andrew Pinski <andrew.pinski@oss.qualcomm.com>
Andrew Pinski [Fri, 15 Aug 2025 23:17:35 +0000 (16:17 -0700)]
Rewrite bool loads for undefined case [PR121279]
Just like r16-465-gf2bb7ffe84840d8 but this time
instead of a VCE there is a full on load from a boolean.
This showed up when trying to remove the extra copy
in the testcase from the revision mentioned above (pr120122-1.c).
So when moving loads from a boolean type from being conditional
to non-conditional, the load needs to become a full load and then
casted into a bool so that the upper bits are correct.
Bitfields loads will always do the truncation so they don't need to
be rewritten. Non boolean types always do the truncation too.
What we do is wrap the original reference with a VCE which causes
the full load and then do a casting to do the truncation. Using
fold_build1 with VCE will do the correct thing if there is a secondary
VCE and will also fold if this was just a plain MEM_REF so there is
no need to handle those 2 cases special either.
Changes since v1:
* v2: Use VIEW_CONVERT_EXPR instead of doing a manual load.
Accept all non mode precision loads rather than just
boolean ones.
* v3: Move back to checking boolean type. Don't handle BIT_FIELD_REF.
Add asserts for IMAG/REAL_PART_EXPR.
Bootstrapped and tested on x86_64-linux-gnu.
PR tree-optimization/121279
gcc/ChangeLog:
* gimple-fold.cc (gimple_needing_rewrite_undefined): Return
true for non mode precision boolean loads.
(rewrite_to_defined_unconditional): Handle non mode precision loads.
gcc/testsuite/ChangeLog:
* gcc.dg/torture/pr121279-1.c: New test.
Signed-off-by: Andrew Pinski <andrew.pinski@oss.qualcomm.com>
Andrew Pinski [Tue, 19 Aug 2025 21:52:18 +0000 (14:52 -0700)]
LIM: Manually put uninit decl into ssa
When working on PR121279, I noticed that lim
would create an uninitialized decl and marking
it with supression for uninitialization warning.
This is fine but then into ssa would just call
get_or_create_ssa_default_def on that new decl which
could in theory take some extra compile time to figure
that out.
Plus when doing the rewriting for undefinedness, there
would now be a VCE around the decl. This means the ssa
name is kept around and not propagated in some cases.
So instead this patch manually calls get_or_create_ssa_default_def
to get the "uninitalized" ssa name for this decl and
no longer needs the write into ssa nor for undefined ness.
Bootstrapped and tested on x86_64-linux-gnu.
gcc/ChangeLog:
* tree-ssa-loop-im.cc (execute_sm): Call
get_or_create_ssa_default_def for the new uninitialized
decl.
Signed-off-by: Andrew Pinski <andrew.pinski@oss.qualcomm.com>
xtensa: Make use of compact insn definition syntax for insns whose have multiple alternatives
The use of compact syntax makes the relationship between asm output,
operand constraints, and insn attributes easier to understand and modify,
especially for "mov<mode>_internal".
* config/xtensa/xtensa.md
(The auxiliary define_split for *masktrue_const_bitcmpl):
Use a more concise function call, i.e.,
(1 << GET_MODE_BITSIZE (mode)) - 1 is equivalent to
GET_MODE_MASK (mode).
* config/xtensa/xtensa.md (mode_bits):
New mode attribute.
(zero_extend<mode>si2): Use the appropriate mode iterator and
attribute to unify "zero_extend[hq]isi2" to this description.
Jakub Jelinek [Mon, 25 Aug 2025 14:29:17 +0000 (16:29 +0200)]
c++: Implement C++ CWG3048 - Empty destructuring expansion statements
The following patch implements the proposed resolution of
https://cplusplus.github.io/CWG/issues/3048.html
Instead of rejecting structured binding size it just builds a normal
decl rather than structured binding declaration.
2025-08-25 Jakub Jelinek <jakub@redhat.com>
* pt.cc (finish_expansion_stmt): Implement C++ CWG3048
- Empty destructuring expansion statements. Don't error for
destructuring expansion stmts if sz is 0, don't call
fit_decomposition_lang_decl if n is 0 and pass NULL rather than
this_decomp to cp_finish_decl.
* g++.dg/cpp26/expansion-stmt15.C: Don't expect error on
destructuring expansion stmts with structured binding size 0.
* g++.dg/cpp26/expansion-stmt21.C: New test.
* g++.dg/cpp26/expansion-stmt22.C: New test.
Jakub Jelinek [Mon, 25 Aug 2025 14:27:35 +0000 (16:27 +0200)]
c++: Check for *jump_target earlier in cxx_bind_parameters_in_call [PR121601]
The following testcase ICEs, because the
/* Check we aren't dereferencing a null pointer when calling a non-static
member function, which is undefined behaviour. */
if (i == 0 && DECL_OBJECT_MEMBER_FUNCTION_P (fun)
&& integer_zerop (arg)
/* But ignore calls from within compiler-generated code, to handle
cases like lambda function pointer conversion operator thunks
which pass NULL as the 'this' pointer. */
&& !(TREE_CODE (t) == CALL_EXPR && CALL_FROM_THUNK_P (t)))
{
if (!ctx->quiet)
error_at (cp_expr_loc_or_input_loc (x),
"dereferencing a null pointer");
*non_constant_p = true;
}
checking is done before testing if (*jump_target). Especially when
throws (jump_target), arg can be (and is on this testcase) NULL_TREE,
so calling integer_zerop on it ICEs.
Fixed by moving the if (*jump_target) test earlier.
2025-08-25 Jakub Jelinek <jakub@redhat.com>
PR c++/121601
* constexpr.cc (cxx_bind_parameters_in_call): Move break
if *jump_target before the check for null this object pointer.
Richard Biener [Mon, 25 Aug 2025 09:02:52 +0000 (11:02 +0200)]
tree-optimization/121638 - missed SLP discovery of live induction
The following fixes a missed SLP discovery of a live induction.
Our pattern matching of those fails because of the PR81529 fix
which I think was misguided and should now no longer be relevant.
So this essentially reverts that fix. I have added a GIMPLE
testcase to increase the chance the particular IL is preserved
through the future.
This shows that how we make some IVs live because of early-break
isn't quite correct, so I had to preserve a hack here. Hopefully
to be investigated at some point.
PR tree-optimization/121638
* tree-vect-stmts.cc (process_use): Do not make induction
PHI backedge values relevant.
Kito Cheng [Mon, 18 Aug 2025 13:42:59 +0000 (21:42 +0800)]
RISC-V: Replace deprecated FUNCTION_VALUE/LIBCALL_VALUE macros with target hooks
The FUNCTION_VALUE and LIBCALL_VALUE macros are deprecated in favor of
the TARGET_FUNCTION_VALUE and TARGET_LIBCALL_VALUE target hooks. This
patch replaces the macro definitions with proper target hook implementations.
This change is also a preparatory step for VLS calling convention support,
which will require additional information that is more easily handled
through the target hook interface.
gcc/ChangeLog:
* config/riscv/riscv-protos.h (riscv_init_cumulative_args): Change
fntype parameter from tree to const_tree.
* config/riscv/riscv.cc (riscv_init_cumulative_args): Likewise.
(riscv_function_value): Replace with new implementation that
conforms to TARGET_FUNCTION_VALUE hook signature.
(riscv_libcall_value): New function implementing TARGET_LIBCALL_VALUE.
(TARGET_FUNCTION_VALUE): Define.
(TARGET_LIBCALL_VALUE): Define.
* config/riscv/riscv.h (FUNCTION_VALUE): Remove.
(LIBCALL_VALUE): Remove.
Andi Kleen [Mon, 4 Aug 2025 00:35:39 +0000 (17:35 -0700)]
Use x86 GFNI for vectorized constant byte shifts/rotates
The GFNI AVX gf2p8affineqb instruction can be used to implement
vectorized byte shifts or rotates. This patch uses them to implement
shift and rotate patterns to allow the vectorizer to use them.
Previously AVX couldn't do rotates (except with XOP) and had to handle
8 bit shifts with a half throughput 16 bit shift.
This is only implemented for constant shifts. In theory it could
be used with a lookup table for variable shifts, but it's unclear
if it's worth it.
The vectorizer cost model could be improved, but seems to work for now.
It doesn't model the true latencies of the instructions. Also it doesn't
account for the memory loading of the mask, assuming that for a loop
it will be loaded outside the loop.
The instructions would also support more complex patterns
(e.g. arbitary bit movement or inversions), so some of the tricks
applied to ternlog could be applied here too to collapse
more code. It's trickier because the input patterns
can be much longer since they can apply to every bit individually. I didn't
attempt any of this.
There's currently no test case for the masked/cond_ variants, they seem
to be difficult to trigger with the vectorizer. Suggestions for a test
case for them welcome.
gcc/ChangeLog:
* config/i386/i386-expand.cc (ix86_vgf2p8affine_shift_matrix):
New function to lookup shift/rotate matrixes for gf2p8affine.
* config/i386/i386-protos.h (ix86_vgf2p8affine_shift_matrix):
Declare new function.
* config/i386/i386.cc (ix86_shift_rotate_cost): Add cost model
for shift/rotate implemented using gf2p8affine.
* config/i386/sse.md (VI1_AVX512_3264): New mode iterator.
(<insn><mode>3): Add GFNI case for shift patterns.
(cond_<insn><mode>3): New pattern.
(<insn><mode>3<mask_name>): Dito.
(<insn>v16qi): New rotate pattern to handle XOP V16QI case
and GFNI.
(rotl<mode>3, rotr<mode>3): Exclude V16QI case.
gcc/testsuite/ChangeLog:
* gcc.target/i386/shift-gf2p8affine-1.c: New test
* gcc.target/i386/shift-gf2p8affine-2.c: New test
* gcc.target/i386/shift-gf2p8affine-3.c: New test
* gcc.target/i386/shift-v16qi-4.c: New test
* gcc.target/i386/shift-gf2p8affine-5.c: New test
* gcc.target/i386/shift-gf2p8affine-6.c: New test
* gcc.target/i386/shift-gf2p8affine-7.c: New test
Jeff Law [Mon, 25 Aug 2025 01:55:44 +0000 (19:55 -0600)]
Fix invalid right shift count with recent ifcvt changes
I got too clever trying to simplify the right shift computation in my recent
ifcvt patch. Interestingly enough, I haven't seen anything but the Linaro CI
configuration actually trip the problem, though the code is clearly wrong.
The problem I was trying to avoid were the leading zeros when calling clz on a
HWI when the real object is just say 32 bits.
The net is we get a right shift count of "2" when we really wanted a right
shift count of 30. That causes the execution aspect of bics_3 to fail.
The scan failures are due to creating slightly more efficient code. THe new
code sequences don't need to use conditional execution for selection and thus
we can use bic rather bics which requires a twiddle in the scan.
I reviewed recent bug reports and haven't seen one for this issue. So no new
testcase as this is covered by the armv7 testsuite in the right configuration.
Bootstrapped and regression tested on x86_64, also verified it fixes the Linaro
reported CI failure and verified the crosses are still happy. Pushing to the
trunk.
gcc/
* ifcvt.cc (noce_try_sign_bit_splat): Fix right shift computation.
H.J. Lu [Sat, 23 Aug 2025 19:50:33 +0000 (12:50 -0700)]
x86: Compile noplt-(g|l)d-1.c with -mtls-dialect=gnu
Compile noplt-gd-1.c and noplt-ld-1.c with -mtls-dialect=gnu to support
the --with-tls=gnu2 configure option since they scan the assembly output
for the __tls_get_addr call which is generated by -mtls-dialect=gnu.
Sam James [Fri, 22 Aug 2025 23:54:01 +0000 (00:54 +0100)]
i386: wire up --with-tls to control -mtls-dialect= default
Allow passing --with-tls= at configure-time to control the default value
of -mtls-dialect= for i386 and x86_64. The default itself (gnu) is not changed
unless --with-tls= is passed.
--with-tls= is already wired up for ARM and RISC-V.
gcc/ChangeLog:
PR target/120933
* config.gcc (supported_defaults): Add tls for i386, x86_64.
* config/i386/i386.h (host_detect_local_cpu): Add tls.
* doc/install.texi: Document --with-tls= for i386, x86_64.
John Ericson [Sat, 23 Aug 2025 02:24:56 +0000 (22:24 -0400)]
driver: Rework for_each_path using C++
The old C-style was cumbersome make making one responsible for manually
creating and passing in two parts a closure (separate function and
*_info class for closed-over variables).
Also thanks to templates we can
- make the return type polymorphic, to avoid casting pointee types.
Note that `struct spec_path` was *not* converted because it is used
multiple times. We could still convert to a lambda, but we would want to
put the for_each_path call with that lambda inside a separate function
anyways, to support the multiple callers. Unlike the other two
refactors, it is not clear that this one would make anything shorter.
Instead, I define the `operator()` explicitly. Keeping the explicit
struct gives us some nice "named arguments", versus the wrapper function
alternative, too.
gcc/ChangeLog:
* gcc.cc (for_each_path): templated, to make passing lambdas
possible/easy/safe, and to have a polymorphic return type.
(struct add_to_obstack_info): Deleted, lambda captures replace
it.
(add_to_obstack): Moved to lambda in build_search_list.
(build_search_list): Has above lambda now.
(struct file_at_path_info): Deleted, lambda captures replace
it.
(file_at_path): Moved to lambda in find_a_file.
(find_a_file): Has above lambda now.
(struct spec_path_info): Reamed to just struct spec_path.
(struct spec_path): New name.
(spec_path): Rnamed to spec_path::operator()
(spec_path::operator()): New name
(do_spec_1): Updated for_each_path call sites.
Signed-off-by: John Ericson <git@JohnEricson.me> Reviewed-by: Jason Merrill <jason@redhat.com>
Nathaniel Shead [Fri, 22 Aug 2025 05:15:01 +0000 (15:15 +1000)]
c++/modules: Provide definitions of synthesized methods outside their defining module [PR120499]
In the PR, we're getting a linker error from _Vector_impl's destructor
never getting emitted. This is because of a combination of factors:
1. in imp-member-4_a, the destructor is not used and so there is no
definition generated.
2. in imp-member-4_b, the destructor gets synthesized (as part of the
synthesis for Coll's destructor) but is not ODR-used and so does not
get emitted. Despite there being a definition provided in this TU,
the destructor is still considered imported and so isn't streamed
into the module body.
3. in imp-member-4_c, we need to ODR-use the destructor but we only got
a forward declaration from imp-member-4_b, so we cannot emit a body.
The point of failure here is step 2; this function has effectively been
declared in the imp-member-4_b module, and so we shouldn't treat it as
imported. This way we'll properly stream the body so that importers can
emit it.
PR c++/120499
gcc/cp/ChangeLog:
* method.cc (synthesize_method): Set the instantiating module.
gcc/testsuite/ChangeLog:
* g++.dg/modules/imp-member-4_a.C: New test.
* g++.dg/modules/imp-member-4_b.C: New test.
* g++.dg/modules/imp-member-4_c.C: New test.
Kishan Parmar [Fri, 22 Aug 2025 18:58:09 +0000 (00:28 +0530)]
rs6000: Add shift count guards to avoid undefined behavior [PR118890]
This patch adds missing guards on shift amounts to prevent UB when the
shift count equals or exceeds HOST_BITS_PER_WIDE_INT.
In the patch (r16-2666-g647bd0a02789f1), shift counts were only checked
for nonzero but not for being within valid bounds. This patch tightens
those conditions by enforcing that shift counts are greater than zero
and less than HOST_BITS_PER_WIDE_INT.
2025-08-23 Kishan Parmar <kishan@linux.ibm.com>
gcc/
PR target/118890
* config/rs6000/rs6000.cc (can_be_rotated_to_negative_lis): Add bounds
checks for shift counts to prevent undefined behavior.
(rs6000_emit_set_long_const): Likewise.
Jeff Law [Fri, 22 Aug 2025 17:53:27 +0000 (11:53 -0600)]
[PR rtl-optimization/120553] Improve selecting between constants based on sign bit test
While working to remove mvconst_internal I stumbled over a regression in
the code to handle signed division by a power of two.
In that sequence we want to select between 0, 2^n-1 by pairing a sign
bit splat with a subsequent logical right shift. This can be done
without branches or conditional moves.
Playing with it a bit made me realize there's a handful of selections we
can do based on a sign bit test. Essentially there's two broad cases.
Clearing bits after the sign bit splat. So we have 0, -1, if we clear
bits the 0 stays as-is, but the -1 could easily turn into 2^n-1, ~2^n-1,
or some small constants.
Setting bits after the sign bit splat. If we have 0, -1, setting bits
the -1 stays as-is, but the 0 can turn into 2^n, a small constant, etc.
Shreya and I originally started looking at target patterns to do this,
essentially discovering conditional move forms of the selects and
rewriting them into something more efficient. That got out of control
pretty quickly and it relied on if-conversion to initially create the
conditional move.
The better solution is to actually discover the cases during
if-conversion itself. That catches cases that were previously being
missed, checks cost models, and is actually simpler since we don't have
to distinguish between things like ori and bseti, instead we just emit
the natural RTL and let the target figure it out.
In the ifcvt implementation we put these cases just before trying the
traditional conditional move sequences. Essentially these are a last
attempt before trying the generalized conditional move sequence.
This as been bootstrapped and regression tested on aarch64, riscv,
ppc64le, s390x, alpha, m68k, sh4eb, x86_64 and probably a couple others
I've forgotten. It's also been tested on the other embedded targets.
Obviously the new tests are risc-v specific, so that testing was
primarily to make sure we didn't ICE, generate incorrect code or regress
target existing specific tests.
Raphael has some changes to attack this from the gimple direction as
well. I think the latest version of those is on me to push through
internal review.
PR rtl-optimization/120553
gcc/
* ifcvt.cc (noce_try_sign_bit_splat): New function.
(noce_process_if_block): Use it.
gcc/testsuite/
* gcc.target/riscv/pr120553-1.c: New test.
* gcc.target/riscv/pr120553-2.c: New test.
* gcc.target/riscv/pr120553-3.c: New test.
* gcc.target/riscv/pr120553-4.c: New test.
* gcc.target/riscv/pr120553-5.c: New test.
* gcc.target/riscv/pr120553-6.c: New test.
* gcc.target/riscv/pr120553-7.c: New test.
* gcc.target/riscv/pr120553-8.c: New test.
Richard Biener [Fri, 22 Aug 2025 12:29:49 +0000 (14:29 +0200)]
Fixups around reduction info and STMT_VINFO_REDUC_VECTYPE_IN
STMT_VINFO_REDUC_VECTYPE_IN exists on relevant reduction stmts, not
the reduction info. And STMT_VINFO_DEF_TYPE exists on the
reduction info. The following fixes up a few places.
* tree-vect-loop.cc (vectorizable_lane_reducing): Get
reduction info properly. Adjust checks according to
comments.
(vectorizable_reduction): Do not set STMT_VINFO_REDUC_VECTYPE_IN
on the reduc info.
(vect_transform_reduction): Query STMT_VINFO_REDUC_VECTYPE_IN
on the actual reduction stmt, not the info.
Pan Li [Wed, 13 Aug 2025 06:01:20 +0000 (14:01 +0800)]
RISC-V: Add testcase for scalar unsigned SAT_MUL form 3
Add run and asm check test cases for scalar unsigned SAT_MUL form 3.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/sat/sat_arith.h: Add test helper macros.
* gcc.target/riscv/sat/sat_u_mul-4-u16-from-u128.c: New test.
* gcc.target/riscv/sat/sat_u_mul-4-u16-from-u32.c: New test.
* gcc.target/riscv/sat/sat_u_mul-4-u16-from-u64.c: New test.
* gcc.target/riscv/sat/sat_u_mul-4-u16-from-u64.rv32.c: New test.
* gcc.target/riscv/sat/sat_u_mul-4-u32-from-u128.c: New test.
* gcc.target/riscv/sat/sat_u_mul-4-u32-from-u64.c: New test.
* gcc.target/riscv/sat/sat_u_mul-4-u32-from-u64.rv32.c: New test.
* gcc.target/riscv/sat/sat_u_mul-4-u64-from-u128.c: New test.
* gcc.target/riscv/sat/sat_u_mul-4-u8-from-u128.c: New test.
* gcc.target/riscv/sat/sat_u_mul-4-u8-from-u16.c: New test.
* gcc.target/riscv/sat/sat_u_mul-4-u8-from-u32.c: New test.
* gcc.target/riscv/sat/sat_u_mul-4-u8-from-u64.c: New test.
* gcc.target/riscv/sat/sat_u_mul-4-u8-from-u64.rv32.c: New test.
* gcc.target/riscv/sat/sat_u_mul-run-4-u16-from-u128.c: New test.
* gcc.target/riscv/sat/sat_u_mul-run-4-u16-from-u32.c: New test.
* gcc.target/riscv/sat/sat_u_mul-run-4-u16-from-u64.c: New test.
* gcc.target/riscv/sat/sat_u_mul-run-4-u16-from-u64.rv32.c: New test.
* gcc.target/riscv/sat/sat_u_mul-run-4-u32-from-u128.c: New test.
* gcc.target/riscv/sat/sat_u_mul-run-4-u32-from-u64.c: New test.
* gcc.target/riscv/sat/sat_u_mul-run-4-u32-from-u64.rv32.c: New test.
* gcc.target/riscv/sat/sat_u_mul-run-4-u64-from-u128.c: New test.
* gcc.target/riscv/sat/sat_u_mul-run-4-u8-from-u128.c: New test.
* gcc.target/riscv/sat/sat_u_mul-run-4-u8-from-u16.c: New test.
* gcc.target/riscv/sat/sat_u_mul-run-4-u8-from-u32.c: New test.
* gcc.target/riscv/sat/sat_u_mul-run-4-u8-from-u64.c: New test.
* gcc.target/riscv/sat/sat_u_mul-run-4-u8-from-u64.rv32.c: New test.
Richard Biener [Thu, 21 Aug 2025 11:41:29 +0000 (13:41 +0200)]
Use REDUC_GROUP_FIRST_ELEMENT less
REDUC_GROUP_FIRST_ELEMENT is often checked to see whether we are
dealing with a SLP reduction or a reduction chain. When we are
in the context of analyzing the reduction (so we are sure
the SLP instance we see is correct), then we can use the SLP
instance kind instead.
* tree-vect-loop.cc (get_initial_defs_for_reduction): Adjust
comment.
(vect_create_epilog_for_reduction): Get at the reduction
kind via the instance, re-use the slp_reduc flag instead
of checking REDUC_GROUP_FIRST_ELEMENT again.
Remove unreachable code.
(vectorizable_reduction): Compute a reduc_chain flag from
the SLP instance kind, avoid REDUC_GROUP_FIRST_ELEMENT
checks.
(vect_transform_cycle_phi): Likewise.
(vectorizable_live_operation): Check the SLP instance
kind instead of REDUC_GROUP_FIRST_ELEMENT.
Nathaniel Shead [Fri, 22 Aug 2025 03:47:43 +0000 (13:47 +1000)]
testsuite: Fix g++.dg/abi/mangle83.C for -fshort-enums
Linaro CI informed me that this test fails on ARM thumb-m7-hard-eabi.
This appears to be because the target defaults to -fshort-enums, and so
the mangled names are inaccurate.
This patch just disables the implicit type enum test for this case.
gcc/testsuite/ChangeLog:
* g++.dg/abi/mangle83.C: Disable implicit enum test for
-fshort-enums.
Richard Biener [Fri, 22 Aug 2025 08:39:33 +0000 (10:39 +0200)]
Decouple parloops from vect reduction infra some more
The following removes the use of STMT_VINFO_REDUC_* from parloops,
also fixing a mistake with analyzing double reductions which rely
on the outer loop vinfo so the inner loop is properly detected as
nested.
* tree-parloops.cc (parloops_is_simple_reduction): Pass
in double reduction inner loop LC phis and query that.
(parloops_force_simple_reduction): Similar, but set it.
Check for valid reduction types here.
(valid_reduction_p): Remove.
(gather_scalar_reductions): Adjust, fixup double
reduction inner loop processing.
Alexandre Oliva [Fri, 22 Aug 2025 00:46:22 +0000 (21:46 -0300)]
[arm] require armv7 support for [PR120424]
Without stating the architecture version required by the test, test
runs with options that are incompatible with the required
architecture version fail, e.g. -mfloat-abi=hard.
armv7 was not covered by the long list of arm variants in
target-supports.exp, so add it, and use it for the effective target
requirement and for the option.
for gcc/testsuite/ChangeLog
PR rtl-optimization/120424
* lib/target-supports.exp (arm arches): Add arm_arch_v7.
* g++.target/arm/pr120424.C: Require armv7 support. Use
dg-add-options arm_arch_v7 instead of explicit -march=armv7.
Dimitar Dimitrov [Sat, 16 Aug 2025 16:51:32 +0000 (19:51 +0300)]
pru: Add options to disable MUL/FILL/ZERO instructions
Older PRU core versions (e.g. in AM1808 SoC) do not support
XIN, XOUT, FILL, ZERO instructions. Add GCC command line options to
optionally disable generation of those instructions, so that code
can be executed on such older PRU cores.
gcc/ChangeLog:
* common/config/pru/pru-common.cc (TARGET_DEFAULT_TARGET_FLAGS):
Keep multiplication, FILL and ZERO instructions enabled by
default.
* config/pru/pru.md (prumov<mode>): Gate code generation on
TARGET_OPT_FILLZERO.
(mov<mode>): Ditto.
(zero_extendqidi2): Ditto.
(zero_extendhidi2): Ditto.
(zero_extendsidi2): Ditto.
(@pru_ior_fillbytes<mode>): Ditto.
(@pru_and_zerobytes<mode>): Ditto.
(@<code>di3): Ditto.
(mulsi3): Gate code generation on TARGET_OPT_MUL.
* config/pru/pru.opt: Add mmul and mfillzero options.
* config/pru/pru.opt.urls: Regenerate.
* config/rl78/rl78.opt.urls: Regenerate.
* doc/invoke.texi: Document new options.
Andrew Pinski [Wed, 20 Aug 2025 22:34:15 +0000 (15:34 -0700)]
c: Add folding of nullptr_t in some cases [PR121478]
The middle-end does not fully understand NULLPTR_TYPE. So it
gets confused a lot of the time when dealing with it.
This adds the folding that is similarly done in the C++ front-end already.
In some cases it should produce slightly better code as there is no
reason to load from a nullptr_t variable as it is always NULL.
The following is handled:
nullptr_v ==/!= nullptr_v -> true/false
(ptr)nullptr_v -> (ptr)0, nullptr_v
f(nullptr_v) -> f ((nullptr, nullptr_v))
The last one is for conversion inside ... .
Bootstrapped and tested on x86_64-linux-gnu.
PR c/121478
gcc/c/ChangeLog:
* c-fold.cc (c_fully_fold_internal): Fold nullptr_t ==/!= nullptr_t.
* c-typeck.cc (convert_arguments): Handle conversion from nullptr_t
for varargs.
(convert_for_assignment): Handle conversions from nullptr_t to
pointer type specially.
gcc/testsuite/ChangeLog:
* gcc.dg/torture/pr121478-1.c: New test.
Signed-off-by: Andrew Pinski <andrew.pinski@oss.qualcomm.com>
Jason Merrill [Thu, 21 Aug 2025 17:52:25 +0000 (13:52 -0400)]
c++: constexpr clobber of const [PR121068]
Since r16-3022, 20_util/variant/102912.cc was failing in C++20 and above due
to wrong errors about destruction modifying a const object; destruction is
OK.
PR c++/121068
gcc/cp/ChangeLog:
* constexpr.cc (cxx_eval_store_expression): Allow clobber of a const
object.
RISC-V: testsuite: Fix DejaGnu support for riscv_zvfh
Call check_effective_target_riscv_zvfh_ok rather than
check_effective_target_riscv_zvfh in vx_vf_*run-1-f16.c run tests and ensure
that they are actually run.
Also fix remove_options_for_riscv_zvfh.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/vx_vf/vf_vfmacc-run-1-f16.c: Call
check_effective_target_riscv_zvfh_ok rather than
check_effective_target_riscv_zvfh.
* gcc.target/riscv/rvv/autovec/vx_vf/vf_vfmadd-run-1-f16.c: Likewise.
* gcc.target/riscv/rvv/autovec/vx_vf/vf_vfmsac-run-1-f16.c: Likewise.
* gcc.target/riscv/rvv/autovec/vx_vf/vf_vfmsub-run-1-f16.c: Likewise.
* gcc.target/riscv/rvv/autovec/vx_vf/vf_vfnmacc-run-1-f16.c: Likewise.
* gcc.target/riscv/rvv/autovec/vx_vf/vf_vfnmadd-run-1-f16.c: Likewise.
* gcc.target/riscv/rvv/autovec/vx_vf/vf_vfnmsac-run-1-f16.c: Likewise.
* gcc.target/riscv/rvv/autovec/vx_vf/vf_vfnmsub-run-1-f16.c: Likewise.
* gcc.target/riscv/rvv/autovec/vx_vf/vf_vfwmacc-run-1-f16.c: Likewise.
* gcc.target/riscv/rvv/autovec/vx_vf/vf_vfwmsac-run-1-f16.c: Likewise.
* gcc.target/riscv/rvv/autovec/vx_vf/vf_vfwnmacc-run-1-f16.c: Likewise.
* gcc.target/riscv/rvv/autovec/vx_vf/vf_vfwnmsac-run-1-f16.c: Likewise.
* lib/target-supports.exp (check_effective_target_riscv_zvfh_ok): Append
zvfh instead of v to march.
(remove_options_for_riscv_zvfh): Remove duplicate and
call remove_ rather than add_options_for_riscv_z_ext.
This PR is another bug in the rtl-ssa code to manage live-out uses.
It seems that this didn't get much coverage until recently.
In the testcase, late-combine first removed a register-to-register
move by substituting into all uses, some of which were in other EBBs.
This was done after checking make_uses_available, which (as expected)
says that single dominating definitions are available everywhere
that the definition dominates. But the update failed to add
appropriate live-out uses, so a later parallelisation attempt
tried to move the new destination into a later block.
gcc/
PR rtl-optimization/121619
* rtl-ssa/functions.h (function_info::commit_make_use_available):
Declare.
* rtl-ssa/blocks.cc (function_info::commit_make_use_available):
New function.
* rtl-ssa/changes.cc (function_info::apply_changes_to_insn): Use it.
gcc/testsuite/
PR rtl-optimization/121619
* gcc.dg/pr121619.c: New test.
Jonathan Wakely [Tue, 19 Aug 2025 17:02:53 +0000 (18:02 +0100)]
libstdc++: Use pthread_mutex_clocklock when TSan is active [PR121496]
This reverts r14-905-g3b7cb33033fbe6 which disabled the use of
pthread_mutex_clocklock when TSan is active. That's no longer needed,
because GCC has TSan interceptors for pthread_mutex_clocklock since GCC
15.1 and Clang has them since 18.1.0 (released March 2024).
The interceptor was added by https://github.com/llvm/llvm-project/pull/75713
libstdc++-v3/ChangeLog:
PR libstdc++/121496
* acinclude.m4 (GLIBCXX_CHECK_PTHREAD_MUTEX_CLOCKLOCK): Do not
use _GLIBCXX_TSAN in _GLIBCXX_USE_PTHREAD_MUTEX_CLOCKLOCK macro.
* configure: Regenerate.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
Jonathan Wakely [Tue, 19 Aug 2025 17:02:53 +0000 (18:02 +0100)]
libstdc++: Check _GLIBCXX_USE_PTHREAD_MUTEX_CLOCKLOCK with #if [PR121496]
The change in r14-905-g3b7cb33033fbe6 to disable the use of
pthread_mutex_clocklock when TSan is active assumed that the
_GLIBCXX_USE_PTHREAD_MUTEX_CLOCKLOCK macro was always checked with #if
rather than #ifdef, which was not true.
This makes the checks use #if consistently.
libstdc++-v3/ChangeLog:
PR libstdc++/121496
* include/std/mutex (__timed_mutex_impl::_M_try_wait_until):
Change preprocessor condition to use #if instead of #ifdef.
(recursive_timed_mutex::_M_clocklock): Likewise.
* testsuite/30_threads/timed_mutex/121496.cc: New test.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
emit the TLS call after NOTE_INSN_BASIC_BLOCK, instead of before
NOTE_INSN_BASIC_BLOCK, to avoid
x.c: In function ‘aout_16_write_syms’:
x.c:54:1: error: NOTE_INSN_BASIC_BLOCK is missing for block 3
54 | }
| ^
x.c:54:1: error: NOTE_INSN_BASIC_BLOCK 77 in middle of basic block 3
during RTL pass: x86_cse
x.c:54:1: internal compiler error: verify_flow_info failed
gcc/
PR target/121607
* config/i386/i386-features.cc (ix86_emit_tls_call): Emit the
TLS call after NOTE_INSN_BASIC_BLOCK in a basic block with only
a label.
gcc/testsuite/
PR target/121607
* gcc.target/i386/pr121607-1a.c: New test.
* gcc.target/i386/pr121607-1b.c: Likewise.
When I added this explicit specialization in r14-1433-gf150a084e25eaa I
used the wrong value for the number of mantissa digits (I used 112
instead of 113). Then when I refactored it in r14-1582-g6261d10521f9fd I
used the value calculated from the incorrect value (35 instead of 36).
Jonathan Wakely [Wed, 20 Aug 2025 15:50:12 +0000 (16:50 +0100)]
libstdc++: Suppress some more additional diagnostics [PR117294]
libstdc++-v3/ChangeLog:
PR c++/117294
* testsuite/20_util/optional/cons/value_neg.cc: Prune additional
output for C++20 and later.
* testsuite/20_util/scoped_allocator/69293_neg.cc: Match
additional error for C++20 and later.
Luc Grosheintz [Mon, 11 Aug 2025 20:14:55 +0000 (22:14 +0200)]
libstdc++: Simplify precomputed partial products in <mdspan>.
Prior to this commit, the partial products of static extents in <mdspan>
was done in a loop that calls a function that computes the partial
product. The complexity is quadratic in the rank.
This commit removes the quadratic complexity.
libstdc++-v3/ChangeLog:
* include/std/mdspan (__static_prod): Delete.
(__fwd_partial_prods): Compute at compile-time in O(rank), not
O(rank**2).
(__rev_partial_prods): Ditto.
(__size): Inline __static_prod.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com> Signed-off-by: Luc Grosheintz <luc.grosheintz@gmail.com>
Luc Grosheintz [Mon, 11 Aug 2025 20:14:54 +0000 (22:14 +0200)]
libstdc++: Reduce size static storage for __fwd_prod in mdspan.
This fixes an oversight in a previous commit that improved mdspan
related code. Because __size doesn't use __fwd_prod, __fwd_prod(__rank)
is not needed anymore. Hence, one can shrink the size of
__fwd_partial_prods.
libstdc++-v3/ChangeLog:
* include/std/mdspan (__fwd_partial_prods): Reduce size of the
array by 1 element.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com> Signed-off-by: Luc Grosheintz <luc.grosheintz@gmail.com>
This patch changes the implementation of the insn to test whether the
result itself is negative or not, rather than the MSB of the result of
the ABS machine instruction. This eliminates the need to consider bit-
endianness and allows for longer branch distances.
/* example */
extern void foo(int);
void test0(int a) {
if (a == -2147483648)
foo(a);
}
void test1(int a) {
if (a != -2147483648)
foo(a);
}
Luc Grosheintz [Sun, 3 Aug 2025 20:57:30 +0000 (22:57 +0200)]
libstdc++: Replace numeric_limit with __int_traits in mdspan.
Using __int_traits avoids the need to include <limits> from <mdspan>.
This in turn should reduce the size of the pre-compiled <mdspan>.
Similar refactoring was carried out for PR92546. Unfortunately,
- There's no mismatching static extents, preventing any
short-circuiting.
- There's a comparison between dynamic and static extents.
- There's one trivial comparison: ... && 3 == 3.
Let E[i] denote the array of static extents, D[k] denote the array of
dynamic extents and k[i] be the index of the i-th extent in D.
(Naturally, k[i] is only meaningful if i is a dynamic extent).
The previous implementation results in assembly that's more or less a
literal translation of:
for (i = 0; i < 3; ++i)
e1 = E1[i] == -1 ? D1[k1[i]] : E1[i];
e2 = E2[i] == -1 ? D2[k2[i]] : E2[i];
if e1 != e2:
return false
return true;
- It eliminated the indirection D[k[i]], because k[i] is known at
compile time. Saving us a comparison E[i] == -1 and conditionally
loading k[i].
- It eliminated the trivial condition 3 == 3.
The result is code that only loads the required values and performs
exactly the number of comparisons needed by the algorithm. It also
results in smaller object files. Therefore, this seems like a sensible
change. We've check several other examples, including fully statically
determined cases and high-rank examples. The example given above
illustrates the other cases well.
The constexpr condition:
if constexpr (!_S_is_compatible_extents<...>)
return false;
is no longer needed, because the optimizer correctly handles this case.
However, it's retained for clarity/certainty.
libstdc++-v3/ChangeLog:
* include/std/mdspan (extents::operator==): Replace loop with
pack expansion.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com> Signed-off-by: Luc Grosheintz <luc.grosheintz@gmail.com>
projects / thirdparty / gcc.git / log
