Jason Merrill [Tue, 19 May 2026 09:15:00 +0000 (05:15 -0400)]
c++: another constexpr empty class tweak
While talking about PR125336, I noticed that we were unnecessarily omitting
a subobject CONSTRUCTOR for non-potentially-overlapping fields of empty
class type. Let's check is_empty_field instead.
Jason Merrill [Thu, 21 May 2026 19:02:21 +0000 (15:02 -0400)]
c++: this capture in template [PR125384]
The r16-1019 change to special-case 'this' capture handling dropped the
'const' qualifier from the capture proxy, so the call to rvalue in
finish_this_expr no longer built a NOP_EXPR to express dropping that
'const'.
PR c++/125384
PR c++/113563
gcc/cp/ChangeLog:
* lambda.cc (build_capture_proxy): 'this' capture proxy is const.
Wilco Dijkstra [Mon, 9 Feb 2026 19:01:19 +0000 (19:01 +0000)]
AArch64: Add PIC/PIE support to large model [PR 123791]
Use an indirection via GOT for data accesses that might be out of range of
ADRP. Using the GOT avoids placing relro symbol references in literal pools
(PR 123791). It also allows the large model to trivially support PIC/PIE.
Constants and readonly data use ADRP since the maximum text size is 2GB in
the large model [1]. The code quality of -mcmodel=large improves dramatically
as a result: codesize of SPEC2017 reduces by 2.2%.
gcc:
PR target/123791
* config/aarch64/aarch64.cc (aarch64_cannot_force_const_mem): Remove
forcing symbol references to const mem.
(aarch64_can_use_per_function_literal_pools_p): Return false for
large model.
(aarch64_use_blocks_for_constant_p): Update comment.
(initialize_aarch64_code_model): Allow PIC/PIE.
(aarch64_classify_symbol): Use SYMBOL_SMALL_ABSOLUTE for constant
references and SYMBOL_SMALL_GOT_4G for writeable data.
Jakub Jelinek [Thu, 21 May 2026 14:26:22 +0000 (16:26 +0200)]
c++: Fix up handling of name independent decls in coroutine lowering [PR125376]
For variables which do have non-NULL DECL_NAME, register_local_var_uses
uses either that name or name_depth_idx (that itself is a bug as it
can clash with user variables named that way) for the fields. In C++26
we can have multiple _ variables in the same scope, so the following
testcase is miscompiled by using the same FIELD_DECL multiple times
(once for the first _ variable, once for the second one).
The following patch fixes it by pretending such variables don't have
a name, so it uses a serial number then instead.
2026-05-21 Jakub Jelinek <jakub@redhat.com>
PR c++/125376
* coroutines.cc (register_local_var_uses): Ignore DECL_NAME for
name independent decls.
Thomas Koenig [Thu, 21 May 2026 13:34:04 +0000 (15:34 +0200)]
Fix PR 125379, ICE with BIND(C) and PRIVATE
This fixes a recent regression introduced by my patch for PR 125902. The
problem was that, for private entities, the symbols cannot be found by
gfc_find_symbol a gsymbol's namespace. This patch uses the approach of
iterating over all the symbols to look for the right name if direct
lookup fails.
gcc/fortran/ChangeLog:
PR fortran/125379
* gfortran.h (gfc_find_symbol_by_name): Add prototype.
* resolve.cc (gfc_verify_binding_labels): Call gfc_find_symbol_by_name
if direct lookup fails.
* symbol.cc (compare_target_sym_name): New function.
(gfc_find_symbol_by_name): New function.
gcc/testsuite/ChangeLog:
PR fortran/125379
* gfortran.dg/binding_label_tests_38.f90: New test.
Xi Ruoyao [Fri, 15 May 2026 03:46:35 +0000 (11:46 +0800)]
riscv: Fix SSP assembly with xtheadmemidx [PR 125320]
The m constraint accepts memory operands suitable for memory load/store
instructions in extensions, not only the ld/sd instructions. So we
cannot always use ld/sd in the SSP instruction sequences.
Call riscv_output_move() for the correct assembly template instead.
PR target/125320
gcc/
* config/riscv/riscv.md (stack_protect_test_<mode>): Call
riscv_output_move() instead of hard coding <load>.
(stack_protect_set_<mode>): Call riscv_output_move() instead of
hard coding <load> and <store>.
Jonathan Wakely [Tue, 19 May 2026 16:44:44 +0000 (17:44 +0100)]
libstdc++: Deprecate numeric_limits::has_denorm for C++23
The paper P2614R2 was approved in Issaquah, 2023. It deprecates the
float_denorm_style enumeration type, its enumerators, and the
numeric_limits::has_denorm and numeric_limits::has_denorm_loss static
data members.
The std/ranges/iota/max_size_type.cc test doesn't get warnings for using
numeric_limits::has_denorm{,_loss} because of PR c++/125406. If that
gets fixed, we'll need two new dg-warning lines in that test.
libstdc++-v3/ChangeLog:
* doc/xml/manual/evolution.xml: Document deprecations.
* doc/html/manual/api.html: Regenerate.
* include/bits/max_size_type.h (numeric_limits::has_denorm):
Mark as deprecated.
(numeric_limits::has_denorm_loss): Likewise.
* include/std/limits (float_denorm_style): Mark as deprecated.
(numeric_limits::has_denorm, numeric_limits::has_denorm_loss):
Mark as deprecated.
* testsuite/18_support/numeric_limits/char16_32_t.cc: Add
dg-warning for expected deprecation warnings.
* testsuite/18_support/numeric_limits/char8_t.cc: Likewise.
* testsuite/18_support/numeric_limits/denorm_min.cc: Likewise.
* testsuite/18_support/numeric_limits/dr559.cc: Likewise.
* testsuite/18_support/numeric_limits/requirements/constexpr_data.cc:
Likewise.
* testsuite/18_support/numeric_limits/specialization_default_values.cc:
Likewise.
* testsuite/std/ranges/iota/max_size_type.cc: Likewise.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
Martin Jambor [Thu, 21 May 2026 12:05:18 +0000 (14:05 +0200)]
ipa-cp: Adjust general IPA-CP cloning heuristics
This winter I have had a long look at the effects of different values
of parameter param_ipa_cp_eval_threshold on performance on SPEC 2017
and on how they affect code size - and how quickly we reach growth
size limit in param_ipa_cp_unit_growth - when compiling these
benchmarks bit also, cc1 in an -O3 bootstrap and clang.
After going through the numbers, it turns out that we tend to clone a
bit too much and especially that we hit the overall growth limit way
too quickly. As a result this patch does two things. First, it
raises the heuristics cost/benefit threshold to 1100 (from 500) which
is the value at which I started to see cloning benefits.
Second, it reverts a recent change to get_max_overall_size where the
size limit also depended on the current call-graph sweep. We only
want the threshold to gradually come down (now to 1100), not the size
constraints also, it turned out to defeat the initial purpose.
gcc/ChangeLog:
2026-04-07 Martin Jambor <mjambor@suse.cz>
* ipa-cp.cc (get_max_overall_size): Remove parameter CUR_SWEEP and
its use.
(decide_about_value): Adjust the call to get_max_overall_size.
(decide_whether_version_node): Likewise.
* params.opt (param_ipa_cp_eval_threshold): Initialize to 1100.
libgomp/ChangeLog:
2026-04-07 Martin Jambor <mjambor@suse.cz>
* testsuite/libgomp.c/ipcp-cb-spec1.c: Set lower param
ipa-cp-eval-threshold.
gcc/testsuite/ChangeLog:
2026-04-07 Martin Jambor <mjambor@suse.cz>
* gcc.dg/ipa/ipa-5.c: Adjust dump.
* gcc.dg/independent-cloneids-1.c: Set lower param
ipa-cp-eval-threshold.
* gcc.dg/vla-1.c: Likewise.
* g++.dg/ipa/devirt-2.C: Add an extra caller of the to-be-cloned
function.
riscv-toolchain-conventions PR #156 defines separate alignment
policies for RV32 Zilsd/Zclsd doubleword memory accesses. Add
-mzilsd-word-align and -mzilsd-strict-align to let users select
the word-aligned and naturally aligned variants explicitly.
Keep the existing -mstrict-align family in the same last-option-wins
option group so code can opt in or out without depending on option
order surprises. When a 2 * XLEN access is not allowed by the
selected policy, expand through scalar bit-field helpers instead of
selecting Zilsd loads or stores.
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc (riscv_handle_option):
Handle Zilsd alignment options and clear the Zilsd-specific
explicit marker for -mstrict-align.
* config/riscv/riscv-opts.h (riscv_zilsd_align_type): New enum.
* config/riscv/riscv-protos.h
(riscv_expand_zilsd_misaligned_move): Declare as void.
(riscv_zilsd_valid_mem_p): Declare.
* config/riscv/riscv.cc (riscv_zilsd_required_align): New
functions.
(riscv_zilsd_valid_mem_p): New function.
(riscv_rtx_costs): Honor Zilsd alignment policy.
(riscv_split_64bit_move_p): Split invalid Zilsd GPR accesses.
(riscv_expand_zilsd_misaligned_move): New function.
(riscv_can_inline_p): Check effective Zilsd alignment policy.
(riscv_override_options_internal): Reject explicit Zilsd
alignment options for RV64.
* config/riscv/riscv.md (movmisaligndi): New expander.
(movmisaligndf): New expander.
* config/riscv/riscv.opt: Add -mzilsd-word-align and
-mzilsd-strict-align.
* config/riscv/riscv.opt.urls: Regenerate.
* doc/invoke.texi: Document the new options.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/zilsd-align-default-1.c: New test.
* gcc.target/riscv/zilsd-align-df-1.c: New test.
* gcc.target/riscv/zilsd-align-rv64-1.c: New test.
* gcc.target/riscv/zilsd-align-rv64-2.c: New test.
* gcc.target/riscv/zilsd-align-rv64-3.c: New test.
* gcc.target/riscv/zilsd-align-rv64-4.c: New test.
* gcc.target/riscv/zilsd-align-word-1.c: New test.
* gcc.target/riscv/zilsd-align-word-2.c: New test.
* gcc.target/riscv/zilsd-align-word-3.c: New test.
* gcc.target/riscv/zilsd-align-word-4.c: New test.
* gcc.target/riscv/zilsd-align-word-5.c: New test.
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
RISC-V C API pull request #183 specifies macros that let users
detect compiler support for intrinsic APIs independent of -march:
https://github.com/riscv-non-isa/riscv-c-api-doc/pull/183
Define __riscv_intrinsic_<extension> macros in the corresponding
RISC-V intrinsic headers. The macros describe compiler support for
an intrinsic API and do not depend on whether the related ISA
extension is enabled by -march.
Derive scalar composite macros from their component macros so they
are only defined when all component intrinsic headers have been
included.
gcc/testsuite/
* gcc.target/riscv/intrinsic-detection-bitmanip.c: New test.
* gcc.target/riscv/intrinsic-detection-crypto.c: New test.
* gcc.target/riscv/intrinsic-detection-scalar-reverse.c: New test.
* gcc.target/riscv/intrinsic-detection-scalar.c: New test.
* gcc.target/riscv/rvv/base/intrinsic-detection.c: New test.
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
RISC-V: Add C API and hwprobe feature bit for zicfiss
riscv-c-api-doc PR #187 defines the RISC-V C API feature bit
for zicfiss as group 1, bit 27. GCC already supports zicfiss,
so add the missing feature-bit metadata and libgcc copy of the
definition.
Upstream Linux exposes zicfiss through RISCV_HWPROBE_KEY_IMA_EXT_1.
Copy the upstream Linux hwprobe constants and map the zicfiss bit
directly to the matching feature bit.
This patch only adds metadata and runtime feature-bit probing. It
does not add ISA extension support.
gcc/ChangeLog:
* common/config/riscv/riscv-ext-bitmask.def: Add zicfiss.
* config/riscv/riscv-ext.def: Add C API bit position for
zicfiss.
libgcc/ChangeLog:
* config/riscv/feature_bits.c (ZICFISS_GROUPID,
ZICFISS_BITMASK, RISCV_HWPROBE_KEY_IMA_EXT_1,
RISCV_HWPROBE_EXT_ZICFISS): Define.
(SET_FROM_IMA_EXT_1): Define.
(__init_riscv_features_bits_linux): Query IMA_EXT_1 and set
zicfiss from the corresponding upstream Linux hwprobe bit.
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
RISC-V: Add Linux hwprobe mappings for existing extensions
Upstream Linux defines hwprobe bits in RISCV_HWPROBE_KEY_IMA_EXT_0
for the following extensions: supm, zicntr, zihpm, zfbfmin, zvfbfmin,
zvfbfwma, zicbom, zaamo, zalrsc, zabha, zalasr, zicbop, zilsd, zclsd,
and zicfilp.
GCC already supports these extensions, and previous patches add the
matching C API feature-bit metadata. Copy the upstream Linux bit
assignments and map them directly to the matching feature bits.
This patch does not synthesize summary or implied extension bits, and
it does not add new ISA support. The PR #185 feature bits depend on
riscv-c-api-doc PR #185.
libgcc/ChangeLog:
* config/riscv/feature_bits.c (RISCV_HWPROBE_EXT_SUPM,
RISCV_HWPROBE_EXT_ZICNTR, RISCV_HWPROBE_EXT_ZIHPM,
RISCV_HWPROBE_EXT_ZFBFMIN, RISCV_HWPROBE_EXT_ZVFBFMIN,
RISCV_HWPROBE_EXT_ZVFBFWMA, RISCV_HWPROBE_EXT_ZICBOM,
RISCV_HWPROBE_EXT_ZAAMO, RISCV_HWPROBE_EXT_ZALRSC,
RISCV_HWPROBE_EXT_ZABHA, RISCV_HWPROBE_EXT_ZALASR,
RISCV_HWPROBE_EXT_ZICBOP, RISCV_HWPROBE_EXT_ZILSD,
RISCV_HWPROBE_EXT_ZCLSD, RISCV_HWPROBE_EXT_ZICFILP): Define.
(__init_riscv_features_bits_linux): Set feature bits from the
corresponding upstream Linux hwprobe bits.
Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
RISC-V: Add C API feature bits from riscv-c-api-doc PR #185
Add RISC-V C API feature bit metadata for these extensions from
riscv-c-api-doc PR #185: supm, zicntr, zihpm, zfbfmin, zvfbfmin,
zvfbfwma, zicbom, zaamo, zalrsc, zabha, zalasr, zicbop, and zicfilp.
This patch only adds metadata. It does not add ISA extension
support or new runtime probing.
gcc/ChangeLog:
* common/config/riscv/riscv-ext-bitmask.def: Add supm,
zicntr, zihpm, zfbfmin, zvfbfmin, zvfbfwma, zicbom,
zaamo, zalrsc, zabha, zalasr, zicbop, and zicfilp.
* config/riscv/riscv-ext.def: Add C API bit positions for
supm, zicntr, zihpm, zfbfmin, zvfbfmin, zvfbfwma,
zicbom, zaamo, zalrsc, zabha, zalasr, zicbop, and
zicfilp.
RISC-V: Add C API feature bits for existing extensions
The RISC-V C API already allocates feature bits for b, e, h,
zilsd, zclsd, zcmp, zifencei, and zmmul. GCC already has
these extensions in riscv-ext.def, but the FMV bitmask table and
the libgcc copy of the bit definitions did not include them.
This patch only adds metadata. It does not add ISA extension
support.
gcc/ChangeLog:
* common/config/riscv/riscv-ext-bitmask.def: Add b, e, h,
zilsd, zclsd, zcmp, zifencei, and zmmul.
Jonathan Wakely [Wed, 1 Apr 2026 22:45:03 +0000 (23:45 +0100)]
libstdc++: Restore allocator constructor for std::packaged_task (P3503R3)
WG21 approved P3503R3 (by me and Nicolas Morales) in Sofia, 2025. The
change is to make std::promise and std::packaged_task be constructible
with an allocator, but not to support general uses-allocator
construction. So they do not have specializations of std::uses_allocator
and do not have an allocator-extended version of every normal
constructor (i.e., no allocator-extended move constructors and for
std::packaged_task, no allocator-extended default constructor).
Since the changes were originally proposed as resolutions to LWG 2095
and LWG 3003, this treats the change as a DR for all standard versions
from C++11 up. This means the constructor semantics are consistent (and
sensible) for all standard versions.
Because I pre-emptively implemented the original resolution of LWG 2095
(in r0-112872-g376d7c51ece6f8), we need to remove the allocator-extended
constructors of std::promise and std::packaged_task which I added but
which are not in the working draft after the P3503R3 changes.
To restore the packaged_task(allocator_arg_t, const Alloc&, F&&)
constructor that was removed by LWG 2921 we just need to remove the #if
that disabled it for C++17 and later.
Finally, we need to remove the std::uses_allocator partial
specialization for std::promise (removed by P3503R3) and the one for
std::packaged_task (already disabled for C++17 and later by LWG 2976).
libstdc++-v3/ChangeLog:
* doc/xml/manual/evolution.xml: Document constructor changes.
* doc/html/*: Regenerate.
* include/std/future (uses_allocator): Remove specializations
for std::promise and std::packaged_task.
(promise(allocator_arg_t, const Alloc&, promise&&)): Remove
constructor proposed for LWG 2095 but not in P3503R3.
(packaged_task(allocator_arg_t, const Alloc&)): Likewise.
(packaged_task(allocator_arg_t, const Alloc&, packaged_task&&)):
Likewise.
(packaged_task(allocator_arg_t, const Alloc&, F&&)): Restore
constructor for C++20 and later.
* testsuite/30_threads/packaged_task/uses_allocator.cc: Adjust
expected result for static_assert.
* testsuite/30_threads/promise/uses_allocator.cc: Likewise.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
Tomasz Kamiński [Fri, 24 Apr 2026 03:25:59 +0000 (05:25 +0200)]
libstdc++: Support integer-class sized range in inplace_vector.
Simply cast size of the input range to size_t, after verifying that
it fits in remaining capacity, and thus in size_t.
libstdc++-v3/ChangeLog:
* include/std/inplace_vector (inplace_vector::assign_range)
(inplace_vector::append_range): Cast ranges::distance(__rg)
to size_t.
* testsuite/23_containers/inplace_vector/cons/from_range.cc: New
test for ranges with integer-class size_type.
* testsuite/23_containers/inplace_vector/modifiers/assign.cc:
Likewise.
* testsuite/23_containers/inplace_vector/modifiers/multi_insert.cc:
Likewise.
Reviewed-by: Patrick Palka <ppalka@redhat.com> Reviewed-by: Jonathan Wakely <jwakely@redhat.com> Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
Xi Ruoyao [Mon, 18 May 2026 14:59:33 +0000 (22:59 +0800)]
LoongArch: Rename rbit<mode> to bitreverse<mode>2 [PR 50481]
r17-523 has added the __builtin_bitreverse{8,16,32,64} builtins and
established that the standard optab names for them are
bitreverse<mode>2. Rename the rbit<mode> expanders so they'll be used
for those builtins.
r17-567 has already removed the uses of rbit<mode> so the old names do
not need to be kept.
PR target/50481
gcc/
* config/loongarch/loongarch.md (@rbit<GPR:mode>2): Rename to
...
(@bitreverse<mode>2): ... this.
(rbithi2): Rename to ...
(bitreversehi2): ... this.
(rbitqi2): Rename to ...
(bitreverseqi2): ... this.
(rbitsi_extended): Rename to ...
(bitreversesi2_extended): ... this.
gcc/testsuite/
* gcc.target/loongarch/la64/bitreverse.c: New test.
Pietro Monteiro [Wed, 20 May 2026 23:33:35 +0000 (19:33 -0400)]
algol68: Add FLOOR as synonym for ENTIER
The Revised Report{10.2.3.4.r} specifies ENTIER as the monadic
operator that yields the greatest integral value less than or equal to
a real value (i.e., rounds toward negative infinity).
Many programming languages call this operator FLOOR. Add FLOOR as a
synonym for ENTIER to allow use of the familiar name; no semantic
change is introduced.
gcc/algol68/ChangeLog:
* a68-parser-prelude.cc (gnu_prelude): Map FLOOR(L real):L int
to ENTIER(L real):L int.
* ga68.texi: Add a section for real operators in the Extended
prelude chapter and document FLOOR.
gcc/testsuite/ChangeLog:
* algol68/execute/entier-1.a68: Add test for FLOOR = ENTIER.
* algol68/compile/floor-1.a68: New test.
Bootstrapped and regression tested on aarch64-linux-gnu with
RUNTESTFLAGS="tree-ssa.exp".
Changes since v1:
* v5: Split testcase into bool, integral, short and float-specific
files.
* v4: Moved match rule to right place alongside other
simple_comparison narrowing cases.
* v3: Simplify match rule.
Add more cases in test file.
* v2: Generalize the match rule to generic narrowing
integral equality comparisons from bool equality.
PR tree-optimization/112533
gcc/ChangeLog:
* match.pd: Add integral narrowing eq/ne to XOR-against-zero
rule for (T)(x) == (T)(y) where precision(T) < precision(x).
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/narrow-bool-eq.c: New test.
* gcc.dg/tree-ssa/narrow-integral-eq.c: New test.
* gcc.dg/tree-ssa/narrow-short-eq.c: New test.
* gcc.dg/tree-ssa/narrow-float-eq.c: New test.
Thomas Koenig [Wed, 20 May 2026 20:43:10 +0000 (22:43 +0200)]
PR fortran/106546 - inline matmul with -fno-automatic
There was a problem caused with allocatable arrays used for
front-end optimization when -fno-automatic was specified.
Solved by explicitly setting the automatic attribute on the
symbol. It required "-O2 -fcheck=bounds -fno-automatic"
to be seen.
gcc/fortran/ChangeLog:
PR fortran/106546
* frontend-passes.cc (create_var): Set attr->automatic on
new symbol.
(create_do_loop): Likewise on iteration variable.
gcc/testsuite/ChangeLog:
PR fortran/106546
* gfortran.dg/inline_matmul_27.f90: New test.
The previous patch removed the only caller of references_value_p
to want the only_useless behaviour. This patch therefore removes
that parameter and converts the function to an iterator.
I don't have numbers to show that using an iterator is better after the
previous patch. But converting to an iterator was the first low-hanging
fruit that I tried for the insn-extract.cc slowness, at a time when
references_value_p accounted for over 50% of compile time on aarch64.
It made a significant difference then.
When bootstrapping with RTL checking enabled, a lot of the
compile time for insn-extract.cc is spent in var-tracking
(~75% on cfarm425, an aarch64 box, and ~42% on my local x86 box).
The top of the aarch64 profile is:
var-tracking uses cselib to track equivalences between values.
However, whereas most cselib passes clear the tables after each
bb/ebb, var-tracking instead retains invariant values for the
whole function. It does this by arranging for invariant values
to be moved from the main hash table to cselib_preserved_hash_table.
cselib_preserved_hash_table is then the first table that is consulted
during a lookup (cselib_find_slot). This allows new non-invariant
locations to be added to an entry of cselib_preserved_hash_table.
These non-invariant locations might be invalidated later, in the
usual way.
At the end of each block, cselib_preserve_only_values invalidates all
registers and memory. It then goes through cselib_preserved_hash_table
to remove locations that have become useless through invalidation.
This never makes a whole value useless, because the invariant
locations still hold.
The issue in insn-extract.cc is that we have many blocks and soon
have many entries in cselib_preserved_hash_table. Very few of those
entries are used in each block, but every location of every entry is
examined after each block.
This patch adds a bit to cselib_val to say whether every location only
references preserved values, and thus will never have useless locations
in its current form. The patch then uses this information to maintain
a list of entries in cselib_preserve_only_values that might have useless
locations. remove_useless_values can then iterate over this list instead
of the whole hash table.
This required finding space for two new bits in cselib_val. Since there
are no holes, I ended up stealing two bits from the hash.
On cfarm425, the effect is to go from:
variable tracking : 709.47 ( 75%) 35M ( 1%)
to:
variable tracking : 1.08 ( 0%) 35M ( 1%)
There was no change to the final object file.
gcc/
* cselib.h (cselib_val::HASH_MASK): New static constant.
(cselib_val::hash): Turn into a 30-bit bitfield.
(cselib_val::in_preserved_table_p): New bitfield.
(cselib_val::all_locs_preserved_p): Likewise.
* cselib.cc: Include rtl-iter.h.
(cselib_preserved_prune_list): New variable.
(cselib_clear_all_locs_preserved): New function.
(new_elt_loc_list): Call it when modifying a value's location list.
(preserve_constants_and_equivs): Set in_preserved_table_p when
moving a value to the preserved hash table. Also push such values
onto cselib_preserved_prune_list.
(cselib_find_slot): Mask out the upper 2 bits of the hash.
(discard_useless_locs): New overload, split out from original
hash table traverse callback. Use an inline rtl iteration
instead of calling references_value_p. Record whether the
retained location only reference preserved value.
(remove_useless_values): Iterate over cselib_preserved_prune_list
instead of the hash table itself. Remove a value from the list
if all remaining locations only reference preserved value.
(new_cselib_val): Initialize the new bitfields.
(cselib_finish): Free cselib_preserved_prune_list.
This is a very minor and perhaps personal change, but when looking at
new_elt_loc_list, I was constantly distracted by the fact that one of
the values is accessed directly ("val") and the other is accessed
indirectly ("CSELIB_VAL_PTR (loc)").
This patch caches the result of CSELIB_VAL_PTR so that all updates
are done on direct cselib_val pointers. It should also be a minor
optimisation, especially when RTL checking is enabled.
David Malcolm [Wed, 20 May 2026 14:24:40 +0000 (10:24 -0400)]
testsuite: add some libstdc++ -fanalyzer test coverage (PR 125236)
This patch adds some test coverage for -fanalyzer's handling of
basic usage of libstdc++ to g++.dg/analyzer/torture, providing
end-to-end testing of the interaction of -fanalyzer and libstdc++ at
various optimization levels.
Currently this is rather minimal (to ensure the tests pass).
I'm working on debugging -fanalyzer issues with other usage patterns
and hope to extend this further as more start working.
gcc/testsuite/ChangeLog:
PR analyzer/125236
* g++.dg/analyzer/torture/README.txt: New.
* g++.dg/analyzer/torture/std-string-ctor-large-literal.C: New
test.
* g++.dg/analyzer/torture/std-string-ctor-small-literal.C: New
test.
* g++.dg/analyzer/torture/std-string-default-ctor.C: New test.
* g++.dg/analyzer/torture/std-unique-ptr-1.C: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
David Malcolm [Wed, 20 May 2026 12:52:29 +0000 (08:52 -0400)]
testsuite: add reduced test for -fanalyzer on std::string [PR125304]
The pointer comparison bug that led to false positives from -fanalyzer
on std::string (by confusing the small-string-optimization and
heap-allocation branches) should be fixed by r17-609-g573b66baa6cb8d.
Add a torture test for this, based on a reduced snapshot of libstdc++,
after preprocessing, with _M_is_local() made public so that we can test
this directly.
gcc/testsuite/ChangeLog:
PR analyzer/125304
* g++.dg/analyzer/torture/std-string-pr125304.C: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
Jonathan Wakely [Tue, 19 May 2026 15:13:15 +0000 (16:13 +0100)]
libstdc++: Use #embed for static tzdata.zi file
This doesn't make much difference to the time taken to compile tzdb.cc
but it is simpler and more maintainable than generating a header in the
makefile.
libstdc++-v3/ChangeLog:
* src/c++20/Makefile.am [USE_STATIC_TZDATA]: Remove targets for
tzdata.zi.h, tzdb.lo and tzdb.o.
* src/c++20/Makefile.in: Regenerate.
* src/c++20/tzdb.cc (tzdata_chars): Use #embed.
(tzdata_stream::ispanbuf): Remove adjustment for extra newline
inserted by the Makefile recipe for tzdata.zi.h.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
Uros Bizjak [Thu, 14 May 2026 16:38:46 +0000 (18:38 +0200)]
i386: Remove TARGET_SHIFT1 tuning feature
All supported versions of GNU as automatically encode "sal $1, reg"
using the shorter implicit-count-1 form (opcode D1), making the
compiler-side i486 TARGET_SHIFT1 / X86_TUNE_SHIFT1 logic redundant.
Remove the tuning feature and simplify all affected shift instruction
patterns by unconditionally emitting the explicit-immediate form and
relying on the assembler to produce the optimal encoding. Update the
length_immediate attributes accordingly to report 0 for const-1 shift
counts, correctly reflecting the assembled output.
Michiel Derhaeg [Wed, 20 May 2026 07:57:09 +0000 (10:57 +0300)]
arc: check if the addend fits when referencing small data memory [PR115650]
This prevents linker errors when referencing small data using large
offsets. In practice it is very unlikely to be a real problem but this
was fixed because other compilers do this check and it ensures the
following tests now succeed:
- gcc.dg/torture/pr60115.c
- gcc.dg/torture/pr105665.c
Jakub Jelinek [Wed, 20 May 2026 07:18:15 +0000 (09:18 +0200)]
i386: Fix up peephole2s with const359_operand [PR125373]
The following testcase ICEs, because the const359_operand peephole2s
optimize multiplication of %rsp by 5 (or could by 3 or 9) into a lea.
Which is not valid, because sp is not a valid index register.
The following patch makes sure to use index_reg_operand predicate instead
so that it won't match for the stack pointer.
2026-05-20 Jakub Jelinek <jakub@redhat.com>
PR target/125373
* config/i386/i386.md
(Convert imul by three, five and nine into lea define_peephole2s): Use
index_reg_operand instead of register_operand.
libstdc++-v3/Changelog:
* config/abi/pre/gnu.ver: Remove recent symbol swept up in
GLIBCXX_3.4.21.
* include/bits/basic_string.tcc (reserve): Guard __limit decl
under #if __cpp_exceptions to quiet warning.
Jakub Jelinek [Wed, 20 May 2026 06:49:06 +0000 (08:49 +0200)]
i386: Use vpaddq + vpermilpd for some non-const permutations [PR125357]
On Tue, May 19, 2026 at 10:30:16AM +0200, Jakub Jelinek wrote:
> On Tue, May 19, 2026 at 10:51:37AM +0300, Alexander Monakov wrote:
> > Thanks for looking at the issue, I really appreciate it. The same problem
> > exists with 64-bit lanes (V2DF/V2SI modes, we fail to utilize vpermilpd).
>
> The control in that case is in bits 1 and 65 rather than 0 and 64.
> So, in order to use vpermilpd for
> __builtin_shuffle (v2di_or_v2df, v2di);
> one would need to first shift the mask (or vpaddq with itself).
> Though, that is still shorter than what we emit right now.
PR target/125357
* config/i386/i386-expand.cc (ix86_expand_vec_perm): For TARGET_AVX
one_operand_shuffle handle also V2DImode and V2DFmode using
vpaddq and vpermilpd.
* gcc.target/i386/avx-pr125357-2.c: New test.
* gcc.target/i386/avx2-pr125357-2.c: New test.
liuhongt [Mon, 5 Jan 2026 02:52:23 +0000 (18:52 -0800)]
Limit outer-loop unswitching by duplicated code size
When unswitching predicates from the innermost loop, hoisting the
unswitch out to an outer loop duplicates only the outer-loop bodies;
the innermost loop is shared. Estimate the cost as
candidate_size - innermost_size and stop selecting an outer loop once
that exceeds param_max_unswitch_insns. innermost_size is hoisted out
of the walk so estimate_loop_insns is called once per level.
gcc/ChangeLog:
* tree-ssa-loop-unswitch.cc (estimate_loop_insns): New function.
(init_loop_unswitch_info): Do not select an outer loop for
unswitching when the duplicated outer-body size exceeds
param_max_unswitch_insns.
Zhou Qiankang [Mon, 18 May 2026 08:03:02 +0000 (16:03 +0800)]
LoongArch: Fix missing plugin header for cpu-features.h [PR125362]
When compiling GCC plugins that include target headers on LoongArch,
the build fails because cpu-features.h is not installed during
`make install-plugin`. The header, included by loongarch-protos.h,
was not listed in any variable that feeds PLUGIN_HEADERS. Add it to
TM_H, following the same approach used by i386 for i386-cpuinfo.h.
Kito Cheng [Tue, 19 May 2026 10:33:52 +0000 (18:33 +0800)]
testsuite: Update CRC dump scan regex for reversed crc table
Before r17-567 ("middle-end: Optimize reversed CRC table-based
implementation"), a reversed CRC without a crc_rev optab was
expanded as: reflect the input, run the non-reversed CRC table,
then reflect the result. So the table that got emitted was the
non-reversed one, and the dump printed:
;; emitting crc table crc_<N>_polynomial_<P> ...
After that patch, the middle end builds a reversed CRC table
directly and the dump prints:
Any target without a crc_rev optab hits the new path. For example,
RISC-V's bitmanip.md defines crc_rev<ANYI1:mode><ANYI:mode>4 with
no TARGET_ guard, so the optab is always there and the dump still
says "using optab for ..." -- the test passes. But x86's
crc_rev<SWI124:mode>si4 needs TARGET_CRC32, so a default x86 build
(no SSE4.2 / -march=cascadelake) has no optab, falls back to the
table, and prints the new "emitting reversed crc table" message.
The old regex only accepted "emitting crc table", so x86 fails.
These tests only call __builtin_rev_crc*, which always take the
reversed path, so the non-reversed "emitting crc table" message
cannot appear here. Just replace it with the new wording.
gcc/testsuite/ChangeLog:
* gcc.dg/crc-builtin-rev-target32.c: Match the new
"emitting reversed crc table" dump message.
* gcc.dg/crc-builtin-rev-target64.c: Likewise.
David Malcolm [Tue, 19 May 2026 19:04:30 +0000 (15:04 -0400)]
analyzer: fix pointer comparisons [PR125304]
PR analyzer/125304 describes a false positive from -fanalyzer on a
trivial use of std::string, due to the analyzer getting confused
about the paths for the small-string optimization versus heap-allocated
strings.
The root cause is a bug in region_svalue::eval_condition which handles
many kinds of pointer comparison, but which seems to have often been
hidden by the optimizer. Previously, it simply compared for identity
of the underlying "region" instance, returning true if identical, false
otherwise. This is wrong:
(a) for some cases, including the above one, different "region" instances
might represent the same memory (and thus we were returning "false" when
we should have returned "true")
(b) for some cases, different "region" instances we might not be able to
determine if they are the same address (and thus we were returning "false"
when we should have returned "unknown")
This patch rewrites region_svalue::eval_condition so that rather than
comparing the regions by identity, it compares their region_offset
values, taking into account their base regions and byte offsets within
those regions. Doing so requires using store::eval_alias, and so the
patch extends that to handle more cases precisely.
This new implementation fixes (a) and (b) above. There are some cases
where precision could be improved (where with the patch we return "unknown"
when we ought to return a known bool), but fixing these would be more
invasive and so are left to followup work.
gcc/analyzer/ChangeLog:
PR analyzer/125304
* common.h (compare_bit_offsets_p): New decl.
(eval_region_offset_comparison): New decl.
* region-model.cc (region_model::on_assignment): Pass *this to
store::set_value to help determination of aliasing.
(region_model::set_value): Likewise.
(region_model::eval_condition): Likewise for
region_svalue::eval_condition.
* region.cc (compare_bit_offsets_p): New.
(region_offset::dump_to_pp): Dump the base region, wrapping the
whole thing in braces.
(eval_byte_offset_comparison): New.
(eval_region_offset_comparison): New.
* store.cc (store::set_value): Add "model" param and pass it to
eval_alias.
(store::eval_alias): Add "model" param and pass to eval_alias_1.
Add early return of true when checking a base region against
itself. Replace final return of "unknown" with logic that
compares the kinds of the two base regions, and may be able
to return "false" rather than "unknown".
(store::eval_alias_1): Add "model" param and pass to eval_alias.
Assert that we have two different base_regions.
(store::replay_call_summary_cluster): Pass model to set_value.
* store.h (store::set_value): Add "model" param.
(store::eval_alias): Likewise.
(store::eval_alias_1): Likewise.
* svalue.cc (region_svalue::eval_condition): Likewise.
Reimplement in terms of eval_region_offset_comparison.
* svalue.h (region_svalue::eval_condition): Add "model" param.
gcc/testsuite/ChangeLog:
PR analyzer/125304
* c-c++-common/analyzer/pointer-comparison-pr125304-eq.c: New test.
* c-c++-common/analyzer/pointer-comparison-pr125304-ge.c: New test.
* c-c++-common/analyzer/pointer-comparison-pr125304-gt.c: New test.
* c-c++-common/analyzer/pointer-comparison-pr125304-le.c: New test.
* c-c++-common/analyzer/pointer-comparison-pr125304-lt.c: New test.
* g++.dg/analyzer/pointer-casts-pr125304.C: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
Marek Polacek [Thu, 14 May 2026 13:27:17 +0000 (09:27 -0400)]
c++: capture of reference to global in template [PR123536]
Thanks to DR 696 (r253266), this works:
int g;
void fn ()
{
int &c = g;
auto l = [] { c++; };
l();
}
because `c` in the lambda body is not an odr-use because we can
evaluate it to a constant and so there's no capture. But when
fn is a template, we reject the code and crash. This patch fixes
both.
Outside a template, the call to maybe_constant_value in mark_use
evaluates `c` to `(int&) &g` but in a template, it remains `c`.
Then we emit an error, and crash on the error_mark_node from
process_outer_var_ref. One of the reasons is
else if (TYPE_REF_P (TREE_TYPE (expression)))
/* FIXME cp_finish_decl doesn't fold reference initializers. */
return true;
in value_dependent_expression_p but even if that changed, we still
wouldn't get the referent because decl_really_constant_value wouldn't
give it to us; the DECL_INITIAL is not a TREE_CONSTANT yet.
So I stopped trying to make this work in a template, and instead
I'm deferring the error in process_outer_var_ref to instantiation
when it's instantiation-dependent. The VAR_P check there is not
to regress the diagnostic in pr57416.C.
The mark_use hunk is to fix a crash on invalid (lambda-const14.C).
PR c++/123536
gcc/cp/ChangeLog:
* cp-tree.h (process_outer_var_ref): Remove a parameter's name.
* expr.cc (mark_use): Return if mark_rvalue_use returns
error_mark_node.
* semantics.cc (process_outer_var_ref): Return decl when it is
instantiation-dependent.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/lambda/lambda-const12.C: New test.
* g++.dg/cpp0x/lambda/lambda-const13.C: New test.
* g++.dg/cpp0x/lambda/lambda-const14.C: New test.
* g++.dg/template/local11.C: New test.
Reviewed-by: Jason Merrill <jason@redhat.com> Reviewed-by: Patrick Palka <ppalka@redhat.com>
Patrick Palka [Tue, 19 May 2026 17:43:10 +0000 (13:43 -0400)]
libstdc++: Fix incorrect move in flat_map::_M_try_emplace [PR125374]
PR libstdc++/125374
libstdc++-v3/ChangeLog:
* include/std/flat_map (_Flat_map_impl::_M_try_emplace): Forward
instead of unconditionally moving __k when inserting it.
* testsuite/23_containers/flat_map/1.cc (test10): New test.
AArch64: Add scalar-to-vector costs for vec_construct
An anti-pattern found in compiled code when predicated tails were
enabled for basic block SLP vectorization was triggered by
byte-reversing patterns in source code, such as:
One reason is that the SLP pass runs before the store-merging
pass gets a chance to coalesce 4 stores into 1 and substitute a
32 bit bswap implementation. Even ignoring that, costing of the
vectorized version (cost: 4) compared to the scalar version
(also 4) was not realistic:
_2 1 times vector_store costs 1 in body
node 0x32ee6d0 1 times vec_construct costs 3 in prologue
There were a couple of contributing issues:
1. the cost of mask construction for the vector_store (ptrue) was
omitted for BB SLP, whereas the loop vectorizer explicitly charges
for it.
2. the cost of vec_construct (elements / 2 + 1) did not incorporate
any GPR-to-SIMD register transfer costs (mov, fmov).
Since the supposed cost of the vectorised code only just reached parity
with the scalar code, addressing either of the above issues would be
sufficient to prevent vectorisation (in this specific case). It is also
less risky than changing the order of passes, and less hacky than
teaching the SLP pass about store-merging.
This commit addresses only the second issue, by adding code in
vector_costs::add_stmt_cost to charge scalar_to_vec_cost for each
element of an external def of kind vec_construct (with specific
exceptions noted below). This cost is added to the base cost
already charged by aarch64_builtin_vectorization_cost for a
vec_construct (which is assumed to cover the cost of the INSR or
equivalent instructions).
This is justifiable because SIMD-to-SIMD insertions into a vector
register generally have lower latency and higher throughput than
GPR-to-SIMD insertions.
The basic structure of the code was copied from commit 90d693bdc9d71841f51d68826ffa5bd685d7f0bc which modified the x86
backend in a similar way, but adapted to use a hash_set<tree>
instead of TREE_VISITED to guard against charging twice or more for
the same scalar op feeding an external def.
This commit assumes that constructing a vector from memory
is no more costly than the equivalent set of scalar loads (or at least
that any difference is incorporated in the cost returned by
aarch64_builtin_vectorization_cost for vec_construct). It also assumes
that constructing a vector from scalar values of floating point type,
from a BIT_FIELD_REF/lastb that extracts from a vector register, or
from the result of a call to an inbuilt reduction function, does not
incur GPR-to-SIMD register transfer costs because such scalars are
typically already in FP/SIMD registers on AArch64.
gcc/ChangeLog:
* config/aarch64/aarch64.cc (aarch64_call_scalar_result_in_simd_reg_p):
New function to determine probabilistically whether a gcall
produces a scalar result in a SIMD/FP register.
(aarch64_scalar_op_to_vec_p): New function to determine
whether or not to add scalar_to_vec_cost per scalar operand
from which a vector is to be constructed.
(aarch64_external_adjust_stmt_cost): New function to adjust the
cost of an SLP tree node for a vec_construct that is fed by
values defined outside the vectorized region.
(aarch64_vector_costs::add_stmt_cost): Call the new
aarch64_external_adjust_stmt_cost function if we have an SLP
node and a vector type.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/sve/vec_construct_1.c: New test.
* gcc.target/aarch64/sve/vec_construct_2.c: New test.
* gcc.target/aarch64/sve/vec_construct_3.c: New test.
* gcc.target/aarch64/sve/vec_construct_4.c: New test.
* gcc.target/aarch64/sve/vec_construct_5.c: New test.
* gcc.target/aarch64/vec-construct-1.c: New test.
* gcc.target/aarch64/vec-construct-10.c: New test.
* gcc.target/aarch64/vec-construct-11.c: New test.
* gcc.target/aarch64/vec-construct-12.c: New test.
* gcc.target/aarch64/vec-construct-2.c: New test.
* gcc.target/aarch64/vec-construct-3.c: New test.
* gcc.target/aarch64/vec-construct-4.c: New test.
* gcc.target/aarch64/vec-construct-5.c: New test.
* gcc.target/aarch64/vec-construct-6.c: New test.
* gcc.target/aarch64/vec-construct-7.c: New test.
* gcc.target/aarch64/vec-construct-8.c: New test.
* gcc.target/aarch64/vec-construct-9.c: New test.
libstdc++: Use allocate_at_least in vector, string (P0401) [PR118030]
Implement as much of allocator<>::allocate_at_least as possible
relying solely on known alignment behavior of standard operator
new.
Use allocator_at_least in string and vector to maximize usage of
actually allocated storage, as revealed by the allocator in use.
For user-supplied allocators this may make a big difference.
Nothing is changed in include/ext/malloc_allocator or others.
They can be updated at leisure, piecemeal.
libstdc++-v3/ChangeLog:
PR libstdc++/118030
* config/abi/pre/gnu.ver: Expose string::_S_allocate_at_least,
_M_create_plus symbols.
* include/bits/alloc_traits.h:
(allocate_at_least): Delegate in allocator_traits<allocator<_Tp>>
specialization to allocator<_Tp>::allocate_at_least, unconditionally;
annotate [[__gnu__::always_inline__]].
(allocate_at_least): Declare "= delete;" in allocator<void>.
* include/bits/allocator.h (allocate_at_least): Delegate to base
allocate_at_least where defined, calling with explicit base-class
qualification, picking up __new_allocator member.
* include/bits/basic_string.h:
(_Alloc_result): Define new type.
(_S_allocate_at_least): Define, using it.
(_S_allocate): Minimize for legacy ABI use only.
(_M_create_plus): Declare.
(_M_create_and_place): Define, abstracting common operations.
(assign): Use _S_allocate_at_least.
* include/bits/basic_string.tcc:
(_M_create_plus): Define.
(_M_replace, reserve): Use _S_allocate_at_least.
(_M_construct, others (3x)): Use _M_create_and_place.
(_M_construct, input iterators): Use _M_create_plus.
(_M_create, _M_assign, reserve, _M_mutate): Same.
* include/bits/memory_resource.h (allocate_at_least): Define,
document.
* include/bits/new_allocator.h (allocate_at_least): Define.
(_S_check_allocation_limit) Define.
(allocate): Use _S_check_allocation_limit.
(_S_max_size): Change from _M_max_size.
(deallocate): Refine "if constexpr" logic.
* include/bits/stl_vector.h:
(_S_max_size): Move to _Vector_base.
(_Alloc_result): Define type.
(_M_allocate_at_least): Define, using allocate_at_least where supported.
(_M_allocate): Delegate to _M_allocate_at_least.
(max_size, _S_check_init_len): Use _S_max_size as moved.
(_M_create_storage, append_range, _M_allocate_and_copy,
_M_replace_storage): Define, abstracting common operations.
(_M_replace_with): Define, likewise.
(_M_range_initialize_n): Use _M_allocate_at_least.
(_M_check_len): Improve logic.
* include/bits/vector.tcc:
(reserve, _M_fill_append, _M_range_insert): Use _M_allocate_at_least
and _M_replace_storage.
(operator=, _M_assign_aux): Use _M_replace_with.
(_M_realloc_insert, _M_realloc_append, _M_default_append, insert_range):
Use _M_allocate_at_least.
(_M_fill_insert): Use _M_replace_storage, normalize whitespace.
* testsuite/util/testsuite_allocator.h:
(allocate_at_least (3x)): Define.
(allocate): Use allocate_at_least.
* testsuite/20_util/allocator/allocate_at_least.cc: Add tests.
* testsuite/21_strings/basic_string/capacity/char/18654.cc:
Loosen capacity check.
* testsuite/21_strings/basic_string/capacity/char/shrink_to_fit.cc:
Same.
* testsuite/21_strings/basic_string/capacity/wchar_t/18654.cc: Same.
* testsuite/21_strings/basic_string/capacity/wchar_t/2.cc: Same.
* testsuite/21_strings/basic_string/capacity/wchar_t/shrink_to_fit.cc:
Same.
* testsuite/23_containers/vector/capacity/shrink_to_fit.cc: Same.
* testsuite/23_containers/vector/capacity/shrink_to_fit2.cc: Same
* testsuite/23_containers/vector/modifiers/emplace/self_emplace.cc:
Adapt to looser reserve behavior.
OpenMP 5.0: Allow multiple clauses mapping same variable
This patch allows multiple clauses on the same construct to map the same
variable, which was not valid in OpenMP 4.5, but allowed in 5.0.
Internally, map clauses have to be deduplicated or merged before reaching the
topological sort in gimplify.cc, lest they might result in a cycle. This happens
in two places: first in the respective front-ends before any clause expansion,
then in the gimplifier just before grouping. The second pass is necessary due to
early clause expansion in the FE reintroducing some duplication (see
map-multi-2.f90).
To make duplicate detection and folding easier in Fortran, enum gfc_omp_map_op
is adjusted to have the two least signficant bits mapped to FROM and TO, similar
to gomp_map_kind in gomp-constants.h
This version of the patch only allows multiple clauses mapping the same variable
on OpenMP code; similar OpenACC code will still be rejected (for now). It also
fixes some minor issues: allow array section bounds to be null and run
target-map-multi-2 only on offload device.
gcc/c/ChangeLog:
* c-typeck.cc (c_finish_omp_clauses): Call omp_remove_duplicate_maps
before clause expansion.
gcc/cp/ChangeLog:
* semantics.cc (finish_omp_clauses): Likewise.
gcc/ChangeLog:
* fold-const.cc (operand_compare::operand_equal_p): Handle
OMP_ARRAY_SECTION.
* gimplify.cc (gimplify_scan_omp_clauses): Call
omp_remove_duplicate_maps after partial clause expansion.
* omp-general.cc (omp_remove_duplicate_maps): New function.
* omp-general.h (omp_remove_duplicate_maps): Declare.
* omp-low.cc (install_var_field): Add new 'tree key_expr = NULL_TREE'
default parameter. Set splay-tree lookup key to key_expr instead of
var if key_expr is non-NULL. Adjust call to install_parm_decl.
Update comments.
(scan_sharing_clauses): Use clause tree expression as splay-tree key
for map/to/from and OpenACC firstprivate cases when installing the
variable field into the send/receive record type.
(lower_oacc_reductions): Adjust to find map-clause of reduction
variable, then create receiver-ref.
(lower_omp_target): Adjust to lookup var field using clause expression.
gcc/fortran/ChangeLog:
* gfortran.h (enum gfc_omp_map_op): Dedicate the two LSB to TO and FROM.
* openmp.cc (resolve_omp_clauses): Adjust to allow duplicate
mapped variables for OpenMP.
* trans-openmp.cc (gfc_trans_omp_clauses): Remove duplicates before
clause expansion.
libgomp/ChangeLog:
* testsuite/libgomp.c++/target-map-multi-1.C: New test.
* testsuite/libgomp.c-c++-common/target-map-iterators-6.c: New test.
* testsuite/libgomp.c-c++-common/target-map-multi-1.c: New test.
* testsuite/libgomp.c-c++-common/target-map-multi-2.c: New test.
* testsuite/libgomp.c-c++-common/target-map-multi-3.c: New test.
* testsuite/libgomp.c-c++-common/target-map-multi-4.c: New test.
* testsuite/libgomp.fortran/target-map-multi-1.f90: New test.
* testsuite/libgomp.fortran/target-map-multi-2.f90: New test.
* testsuite/libgomp.fortran/target-map-multi-3.f90: New test.
* testsuite/libgomp.fortran/target-map-multi-4.f90: New test.
* testsuite/libgomp.fortran/target-map-multi-5.f90: New test.
gcc/testsuite/ChangeLog:
* c-c++-common/gomp/clauses-2.c: Adjust testcase.
* c-c++-common/gomp/map-6.c: Adjust testcase.
* gfortran.dg/gomp/pr107214.f90: Adjust testcase.
* c-c++-common/gomp/map-multi-1.c: New test.
* c-c++-common/gomp/map-multi-2.c: New test.
* gfortran.dg/gomp/map-multi-1.f90: New test.
* gfortran.dg/gomp/map-multi-2.f90: New test.
Thomas Koenig [Tue, 19 May 2026 12:09:35 +0000 (14:09 +0200)]
PR fortran/115260 - fix data corruption on inline packing/unpacking
This patch fixes a data corruption occuring when a non-contiguous slice of an
allocatable array component was passed to a procedure expecting a g77-style
argument. The problem was the inline packing (PR fortran/88821) which went
astray gfc_trans_scalar_assign was told to deallocate the argument upon
return.
The solution was to not pass that argument if passing a g77-style array,
in effect a one-liner.
This is a regression which goes back to all supported releases.
gcc/fortran/ChangeLog:
PR fortran/115260
* trans-expr.cc (gfc_conv_subref_array_arg): Pass false to
dealloc argument of gfc_trans_scalar_assign if we are
converting a g77-style argument.
gcc/testsuite/ChangeLog:
PR fortran/115260
* gfortran.dg/pr115260.f90: New test.
Georg-Johann Lay [Tue, 19 May 2026 11:33:00 +0000 (13:33 +0200)]
AVR: Add bitreverseqi2 insns.
Now that https://gcc.gnu.org/r17-591 has been applied, the
middle-end will express 8-bit bitreverse code in terms of
a 16-bit bitreverse. Therefore, add bitreverseqi2 insns.
PR target/50481
gcc/
* config/avr/avr.md (bitreverseqi2): New insn-and-split.
(*bitreverseqi2): New insn.
Roger Sayle [Tue, 19 May 2026 11:29:08 +0000 (07:29 -0400)]
i386: Optimize ptestz(x,-1) as ptestz(x,x) on x86
This patch, inspired by PR target/90483 and libstdc++/118416, implements
some RTL expansion-time simplifications of ptest. A common idiom for
testing a vector against zero is to use ptestz(mask,-1). Alas the code
generated for this is suboptimal, requiring materialization of an all_ones
vector. Given that ptestz(x,y) is defined as (x & y) == 0, an equivalent
form is ptestz(mask,mask), saving an instruction (if ~0 isn't available).
Consider the function:
typedef long long v2di __attribute__ ((__vector_size__ (16)));
int foo (v2di x)
{
return __builtin_ia32_ptestz128(x,~(v2di){0,0});
}
foo: xorl %eax, %eax
vptest %xmm0, %xmm0
sete %al
ret
2026-05-19 Roger Sayle <roger@nextmovesoftware.com>
gcc/ChangeLog
PR target/90483
PR libstdc++/118416
* config/i386/i386-expand.cc (ix86_expand_sse_ptest): Refactor
with optimizations for PTESTZ*, PTESTC* and PTESTNZC*, including
transforming ptestz(x,-1) into ptestz(x,x).
gcc/testsuite/ChangeLog
PR target/90483
PR libstdc++/118416
* gcc.target/i386/sse4_1-ptest-8.c: New test case.
* gcc.target/i386/sse4_1-ptest-9.c: Likewise.
arm: Fix MVE load/store with writeback intrinsics [PR124870]
These intrinsics (vldr*_gather_base_wb, vstr*_scatter_base_wb) lacked
modelling of memory accesses corresponding to writeback: in this case,
they both read and write memory.
Jonathan Wakely [Mon, 18 May 2026 14:44:21 +0000 (15:44 +0100)]
libstdc++: Make chrono::parse fail for bad %z [PR125369]
The chrono parsing code failed to check for errors when parsing input to
match %z. The expected input is [+-]hh[mm] but if we read less than two
valid digits for the hh or mm parts we didn't set failbit in the stream,
and used the -1 error values returned for each bad digit in the offset
value. This resulted in a "successful" parse that produced a value like
-11h or -11min for the time zone offset.
libstdc++-v3/ChangeLog:
PR libstdc++/125369
* include/bits/chrono_io.h (__detail::_Parser::operator()):
Check for errors when parsing digits for a %z format.
* testsuite/std/time/parse/125369.cc: New test.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
Andrew Pinski [Sun, 17 May 2026 21:32:33 +0000 (14:32 -0700)]
tree: Move unshare_expr from gimplifier to generic tree
We use unshare_expr in many places now outside of gimple
even. So it makes sense to move the decl to tree.h.
A few sources can now even not need to include gimplify.h;
I have not checked all of them just a few which seemed
like including gimplify.h didn't make sense.
This also moves the implementations of unshare_expr,
unshare_expr_without_location and copy_if_shared from gimplify.cc
to tree.cc to keep the headers "clean".
Jakub Jelinek [Tue, 19 May 2026 08:11:08 +0000 (10:11 +0200)]
i386: Use vpermilps for some non-const permutations [PR125357]
We don't use vpermilps insn for V4S[IF]mode variable permutations on
TARGET_AVX without TARGET_AVX512*. For TARGET_AVX512* there are plenty
of permutation instructions already. For TARGET_AVX2, the function has
special cases for one_operand_shuffle for V8SImode/V8SFmode and emits
reasonable code, but for V4SImode/V4SFmode with TARGET_AVX2 it handles
those using V8SImode/V8SFmode as two operand shuffle, which requires
2 preparation instructions, vpermd and one finalization instruction.
And for !TARGET_AVX2 && TARGET_AVX we just emit terrible code for these.
So, the following patch uses vpermilps for V4S[IF]mode one_operand_shuffle.
Trying to handle V8S[IF]mode is not worth it, for TARGET_AVX2 we already
emit good code (see above) and for !TARGET_AVX2 && TARGET_AVX V8SImode
mask is not valid vector mode, so we emit terrible code no matter what.
2026-05-19 Jakub Jelinek <jakub@redhat.com>
PR target/125357
* config/i386/i386-expand.cc (ix86_expand_vec_perm): For
one_operand_shuffle if TARGET_AVX and not TARGET_AVX512F use
vpermilps for V4SImode/V4SFmode. Formatting fix.
* gcc.target/i386/avx-pr125357.c: New test.
* gcc.target/i386/avx2-pr125357.c: New test.
Jakub Jelinek [Tue, 19 May 2026 07:29:33 +0000 (09:29 +0200)]
optabs: Handle bitreverse using widening or two bitreverses of halves [PR50481]
The following patch extends the widen_bswap and expand_doubleword_bswap
functions to handle also bitreverse, so that all the backends with
say just bitreversesi2 or bitreverse{s,d}i2 can handle also
bitreverse{q,h}i2 and bitreverse{d,t}i2 easily.
2026-05-19 Jakub Jelinek <jakub@redhat.com>
PR target/50481
* optabs.cc (widen_bswap): Add UNOPTAB argument and use it instead
of hardcoded bswap_optab. Rename to ...
(widen_bswap_or_bitreverse): ... this.
(expand_doubleword_bswap): Add UNOPTAB argument and use it instead
of hardcoded bswap_optab. Rename to ...
(expand_doubleword_bswap_or_bitreverse): ... this.
(expand_bitreverse): Use widen_bswap_or_bitreverse and
expand_doubleword_bswap_or_bitreverse.
(expand_unop): Adjust widen_bswap and expand_doubleword_bswap callers
to use new names and add an extra bswap_optab argument.
Reviewed-by: Jeffrey Law <jeffrey.law@oss.qualcomm.com>
Robin Dapp [Wed, 13 May 2026 18:39:13 +0000 (20:39 +0200)]
RISC-V: Guard 64-bit vec_extract.
Currently, reduc-6.c fails on the trunk when compiling for 32 bit.
We emit a pred_extract_first of a V2DImode during legitimization of
a move. Normally, we would split that insn into two 32-bit extracts
but this splitter needs to be able to create pseudos which it can't
after reload. The insn here is created during reload when we can still
create pseudos. This patch just piggybacks on the existing handling
when no 64-bit vector elements are available (!TARGET_VECTOR_ELEN64).
Thus, we don't emit 64-bit extracts and don't need to rely on splitting
late.
PR target/125097
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_legitimize_move): Emit 32-bit
vec_extracts right away.
Robin Dapp [Fri, 23 Jan 2026 15:15:42 +0000 (16:15 +0100)]
RISC-V: Remove cbranch_all patterns.
When first introducing the cbranch_any/_all patterns I messed up the all
pattern. After giving it more thought, I removed the patterns entirely.
Our current early-break handling via autovec-opt.md is not ideal but
similar to what the patterns would give us, so no need for confusion.
The situation will improve anyway once the no-scalar-epilogue early-break
patches land.
While at it, I tried unifying the int and float comparison emitter
functions. The latter now also has "mask" capabilities.
Jeevitha [Tue, 19 May 2026 02:58:50 +0000 (21:58 -0500)]
rs6000: Adding missed ISA 3.0 atomic memory operation instructions
Changes to amo.h include the addition of the following load atomic
operations: Compare and Swap Not Equal, Fetch and Increment Bounded,
Fetch and Increment Equal, and Fetch and Decrement Bounded.
Additionally, Store Twin is added for store atomic operations.
2026-05-19 Peter Bergner <bergner@linux.ibm.com>
Jeevitha Palanisamy <jeevitha@linux.ibm.com>
Andi Kleen [Mon, 18 May 2026 15:40:53 +0000 (08:40 -0700)]
Fix masm ptwrite again
The earlier 64bit ptwrite as 32bit fix broke Intel syntax output. Handle
that too by using an alternative. In Intel syntax the instruction
data type is defined by the operands.
I'll commit it as obvious in a day or so for 15/16/trunk, unless there
are objections.
PR target/125351
gcc/ChangeLog:
* config/i386/i386.md: Use alternative to handle masm ptwrite
syntax.
Andrew Pinski [Mon, 18 May 2026 23:30:12 +0000 (16:30 -0700)]
testsuite: Fix pr112095.c for veclowering
Basically we need to test earlier in release_ssa instead
of optimization which is before vec lowering happens.
Also "return a_" to be expanded to match "<retval> = a_"
for vector types that return via memory.
Also add -Wno-psabi to avoid a warning/note about the vector
argument.
Pushed as obvious after testing on x86_64-linux-gnu with both
-m64 and -m32/-mno-sse to invoke the cases that matter here.
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/pr112095.c: Add -Wno-psabi to the options.
Look at release_ssa instead of optimization. Match
"<retval> = a_" in addition to "return a_".
Signed-off-by: Andrew Pinski <andrew.pinski@oss.qualcomm.com>
Jonathan Wakely [Mon, 18 May 2026 22:38:19 +0000 (23:38 +0100)]
libstdc++: Move std::bitset test to correct directory
I added this test in r16-3435-gbbc0e70b610f19 but I'd previously moved
the rest of the bitset tests under 20_util, in r13-2778-g4b4b51445f7f3d.
This moves the lwg4294.cc test where it belongs.
Xin Wang [Mon, 18 May 2026 22:00:15 +0000 (16:00 -0600)]
[PATCH v2] tree-optimization: Fix profile update in loop splitting (initial_true=false)
When split_loop does iteration space splitting, split_at_bb_p may
swap the guard condition so that operand 0 is always the loop IV
and operand 1 is the invariant. For example, "t < i" (LT_EXPR)
becomes "i > t" (GT_EXPR). This can cause initial_true to be
false, meaning loop1 handles iterations where the guard is false
and loop2 handles iterations where the guard is true.
The profile update code used true_edge->probability for loop1 and
its inverse for loop2. That is correct only when loop1 keeps the
true branch. When initial_true is false, loop1 keeps the false
branch and loop2 keeps the true branch, so all profile quantities
must follow those semantic edges instead of the raw true/false edge
names.
Derive loop1_edge and loop2_edge once from initial_true and use them
consistently for loop_version's then probability, the split-loop BB
count scaling, and the iteration estimate scaling. Also make
fix_loop_bb_probability take loop1/loop2 edges explicitly, rather
than assuming its arguments are true/false edges.
The bug caused BB counts in the split loops to be swapped when
initial_true is false: the loop body whose guard is forced false
(loop1, executing fewer iterations) would get the higher profile
count, and vice versa. It could also leave the precondition edge
probabilities and iteration estimates based on the wrong split edge.
gcc/ChangeLog:
* tree-ssa-loop-split.cc (fix_loop_bb_probability): Rename
parameters from true_edge/false_edge to loop1_edge/loop2_edge
and scale both loops directly from their semantic edge
probabilities.
(split_loop): Derive loop1_edge and loop2_edge from initial_true.
Use them for loop1_prob, fix_loop_bb_probability, and iteration
estimate scaling.
Jeff Law [Mon, 18 May 2026 21:24:02 +0000 (15:24 -0600)]
[RISC-V] Improve SI->DI zero/sign extension patterns for RISC-V
-- From the original submission in Oct 2025 --
So this is a slightly scaled back variant of a patch I've been working
on. I'd originally planned to handle both zero and sign extensions, but
there's some fallout with the sign extension adjustments that I'm going
to need more time to tackle. This piece stands on its own and unlocks a
subsequent patch to improve codegen. No sense in having it possibly
miss the merge window.
This patch adjusts the core zero-extension patterns as well as one
closely related combiner pattern.
For the named expanders, we now generate shift pairs if the Zba/Zbb
extensions are not available and the source operand is a REG. Things
are kept as-is for MEMs.
The existing define_insn_and_split it turned into a define_insn that
only handles MEM sources. Those instructions are always available, so
no need to mess with shift pairs. This avoids regressions with a
follow-up patch which enhances a closely related combiner pattern.
That closely related combiner pattern is a define_insn_and_split which
can now turn into a simpler define_split. So that's adjusted as well.
The net is we drop 3 define_insn_and_splits and occasionally get better
code as a result. It also makes it possible to improve some additional
cases which I'll handle as a followup.
The test changes are minimal and mostly related to making sure we have
the right Zb* things enabled based on what the test relies on under the
hood. It's not even clear that part of the change is strictly necessary
anymore. I see it more as test hygiene than anything.
This has been bootstrapped and regression tested on the Pioneer which is
a good test since it doesn't have any of the Zb* extensions and thus
relies heavily on the shift-pair approach to zero extensions.
riscv32-elf and riscv64-elf have also been regression tested. The BPI
hasn't started chewing on this patch yet.
--
Subsequent changes were to the testsuite to ensure that --with-cpu or
--with-tune configure time options wouldn't impact the testresults.
gcc/
* config/riscv/riscv.cc (riscv_rtx_costs): Properly cost pack insns
for Zbkb.
* config/riscv/riscv.md (zero_extendsidi2): Expand into shift pairs
when the appropriate instructions are not available.
(zero_extendhi<GPR:mode>2): Simlarly.
(*zero_extendsidi2_internal): Make a simple define_insn. Only handle
MEM sources.
(*zero_extendhi<GPR2:mode>2): Similarly.
(zero_extendsidi2_shifted): Turn into a define_split and generalize
to handle more constants.
* config/riscv/predicates.md (dimode_shift_operand): New predicate.
gcc/testsuite/
* gcc.target/riscv/slt-1.c: Skip for -Oz as well. Set explicit branch
cost.
* gcc.target/riscv/zba-shNadd-04.c: Add Zbb to command line switches.
* gcc.target/riscv/zba-slliuw.c: Add Zbs to command line switches.
* gcc.target/riscv/zbs-zext.c: Add Zbs to command line switches.
* gcc.target/riscv/shift-shift-6.c: New test.
* gcc.target/riscv/shift-shift-7.c: New test.
* gcc.target/riscv/amo/a-rvwmo-load-relaxed.c: Accept lh or lhu.
* gcc.target/riscv/amo/a-ztso-load-relaxed.c: Accept lh or lhu.
* gcc.target/riscv/amo/zalasr-rvwmo-load-relaxed.c: Accept lh or lhu.
* gcc.target/riscv/amo/zalasr-ztso-load-relaxed.c: Accept lh or lhu.
* gcc.target/riscv/pr105314.c: Set explicitly branch cost.
* gcc.target/riscv/pr105314-rtl.c: Set explicitly branch cost.
Jeff Law [Mon, 18 May 2026 21:17:27 +0000 (15:17 -0600)]
[RISC-V] Improve ext-dce's live bit tracking for IOR/AND with a constant argument
Investigation of a regression with some RISC-V target changes exposed a clear
missed optimization in ext-dce.c
In particular if we mask off bits via a logical AND, then the masked off bits
are not live-in for the other input. Tracking that can in turn allow us to
eliminate more extensions. There's a similar case for logical IOR when it
unconditionally turns bits on.
So if we look at this testcase:
typedef long unsigned int size_t;
struct function
{
unsigned int curr_properties;
unsigned int last_verified;
};
extern struct function *cfun;
andi a5,a0,32
sext.w a0,a0
beq a5,zero,.L2
bseti a0,a0,15
.L2:
lui a5,%hi(cfun)
ld a5,%lo(cfun)(a5)
andi a0,a0,28
sw a0,4(a5)
ret
Note carefully the 2nd andi instruction. That's unconditionally turning off
bits 32..63 (and others). Thus those bits are not relevant/live for the
incoming value in a0. Walking backwards we find the sext.w which sign extends
from bit 31 into bits 32..63. But with bits 32..63 not being live, the sext.w
is useless.
After this patch we get:
andi a5,a0,32
beq a5,zero,.L2
bseti a0,a0,15
.L2:
lui a5,%hi(cfun)
ld a5,%lo(cfun)(a5)
andi a0,a0,28
sw a0,4(a5)
ret
It doesn't trigger often based on my quick testing.
Bootstrapped and regression tested on various targets including x86 and riscv.
Also tested on the usual assortment of embedded targets in my tester. I'll
wait for pre-commit CI to give a final verdict.
gcc/
* ext-dce.cc (carry_backpropagate): Handle AND and IOR with a constant argument.
This param name is confusing, due to it changing meaning in r16-6063-g0b786d961d4426. Update the name to better express what it now
controls, and clarify the wording of the warning that fires when that
limit is hit by the analyzer, and to give more info.
gcc/analyzer/ChangeLog:
* analyzer.opt (-param=analyzer-bb-explosion-factor=): Rename to...
(-param=analyzer-supernode-explosion-factor=): ...this.
* engine.cc (exploded_graph::process_worklist): Update for change
to param name. Clarify the -Wanalyzer-too-complex message when
hitting the overall limit on enodes by also showing the number
of snodes.
gcc/ChangeLog:
* doc/analyzer.texi: Update for change in param name.
* doc/params.texi: Likewise. Clarify wording.
gcc/testsuite/ChangeLog:
* c-c++-common/analyzer/fibonacci.c: Update for change in message
wording.
* c-c++-common/analyzer/raw-data-cst-pr117262-1.c: Update for
change in param name.
* gcc.dg/analyzer/explode-2a.c: Likewise.
* gcc.dg/analyzer/pr93032-mztools-signed-char.c: Likewise.
* gcc.dg/analyzer/pr93032-mztools-unsigned-char.c: Likewise.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
David Malcolm [Mon, 18 May 2026 20:18:38 +0000 (16:18 -0400)]
Modernize class optrecord_json_writer
No functional change intended.
gcc/ChangeLog:
* dump-context.h (dump_context::emit_optinfo): "info" is non-null,
so pass it by reference.
* dumpfile.cc (dump_context::end_any_optinfo): Update for above
change.
(dump_context::emit_optinfo): Likewise.
* optinfo-emit-json.cc: Update throughout to eliminate naked "new"
and "delete" in favor of std::make_unique and unique_ptr. Drop
redundant dtor. Use nullptr rather than NULL. Pass by
const-reference rather than by const-pointer in the places that
require non-null.
* optinfo-emit-json.h: Likewise.
* optinfo.cc (optinfo::emit_for_opt_problem): Update for above
changes.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
Jonathan Wakely [Sun, 17 May 2026 18:27:11 +0000 (19:27 +0100)]
libstdc++: Reduce iterations in PSTL test for Debug Mode
This test often times out, especially on machines with a large number of
cores when the tests are run with a lot of parallel jobs. I suspect that
TBB creates a lot of threads due to std::hardware_concurrency() being a
large number, but because most cores are already busy running other
tests (due to `make -jN check` with large N) the system gets
oversubscribed. In Debug Mode, the testcase runs much slower, and often
times out.
It's probably fine to just test with fewer iterations when Debug Mode is
active.
libstdc++-v3/ChangeLog:
* testsuite/25_algorithms/pstl/alg_sorting/minmax_element.cc:
Reduce iterations for debug mode.
Avi Kivity [Thu, 26 Feb 2026 17:59:41 +0000 (19:59 +0200)]
libstdc++: optimize std::uninitialized_move{,_n}() to memcpy when possible [PR121789]
std::uninitialized_move{,_n} delegates to the corresponding
std::uninitialized_copy() variant after wrapping with a move
iterator, but the std::uninitialized_copy() doesn't unwrap the
move iterator, therefore losing the memcpy optimization if the
iterators were just pointers.
Fix this by unwrapping the move iterator using __miter_base().
We remove operator-() in testsuite_greedy_ops.h; otherwise it breaks
the range size computation.
libstdc++v3/Changelog:
PR libstdc++/121789
* include/bits/stl_uninitialized.h (uninitialized_copy):
Unwrap move iterators
* testsuite/20_util/specialized_algorithms/uninitialized_move/121789.cc:
New test.
* testsuite/util/testsuite_greedy_ops.h (greedy_ops): Comment
out operator-(T, T).
Tomasz Kamiński [Thu, 14 May 2026 12:47:03 +0000 (14:47 +0200)]
libstdc++: Include range_access.h from <valarray>
This implements <valarray> related parts of section 4.8. of P3016R6.
This is treated as DR against C++11 (to expose array begin/end), to follow
similar changes to other semi-containers that were accepted as LWG issues
and treated as DR: <optional> (LWG4131), <stacktrace> (LWG3625).
libstdc++-v3/ChangeLog:
* include/std/valarray [__cplusplus >= 201103L]: Include
<bits/ranges_access.h>.
* testsuite/26_numerics/valarray/range_access2.cc: Remove
<iterator> include, and add test for std::size.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com> Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
Yoshinori Sato [Mon, 18 May 2026 12:50:58 +0000 (06:50 -0600)]
[PATCH] RX: The size of the mov instruction will be corrected
> THanks. There's still work to do. I spun my tester after this change
> on the rx port:
>
> Tests that now fail, but worked before (431 tests):
>
> I won't list them all. Given how many are execution failures, there's
> likely a code generation failure in there somewhere.
> A few of them:
>
> rx-sim: gcc: gcc.c-torture/execute/20001009-2.c -O0 execution test
> rx-sim: gcc: gcc.c-torture/execute/20020614-1.c -O0 execution test
> rx-sim: gcc: gcc.c-torture/execute/20050410-1.c -O1 execution test
> rx-sim: gcc: gcc.c-torture/execute/20050410-1.c -O2 execution test
> rx-sim: gcc: gcc.c-torture/execute/20050410-1.c -O2 -flto
> -fno-use-linker-plugin -flto-partition=none execution test
> rx-sim: gcc: gcc.c-torture/execute/20050410-1.c -O3 -g execution test
> rx-sim: gcc: gcc.c-torture/execute/20050410-1.c -Os execution test
> rx-sim: gcc: gcc.c-torture/execute/921016-1.c -O0 execution test
> rx-sim: gcc: gcc.c-torture/execute/960311-1.c -O1 execution test
> rx-sim: gcc: gcc.c-torture/execute/960311-2.c -O1 execution test
> rx-sim: gcc: gcc.c-torture/execute/980617-1.c -O0 execution test
> rx-sim: gcc: gcc.c-torture/execute/990324-1.c -O0 execution test
> rx-sim: gcc: gcc.c-torture/execute/990326-1.c -O0 execution test
>
> Anyway, seems like something for Yoshinori to look into.
The code extension was causing incorrect output.
Optimization mitigated this issue, so I didn't notice it.
The attached changes now allow the test to pass.
When expanding `extendqisi2` or `extendhisi2`, incorrect operation size
instructions were sometimes output.
This update ensures that the operation size is determined reliably.
gcc/
* config/rx/rx.cc (rx_gen_move_template): Select the mode with the smallest size
for the mov instruction.
This patch generates a reversed polynomial lookup table directly,
eliminating the need for bit reflection operations. The new algorithm:
for (int i = 0; i < data_bit_size / 8; i++)
crc = (crc >> 8) ^ table[(crc ^ (data >> (i * 8))) & 0xFF];
This improves code generation for all targets using table-based reversed
CRC, as it removes the overhead of reflecting input data and CRC values.
Note on code size: one could imagine sharing a single (non-reversed) table
between programs that compute both reversed and non-reversed CRCs in order
to save space under -Os. A survey of ~10k Fedora packages (by Mariam and
Jeff Law) found no package that uses both flavors in the same binary, so
this case is not worth optimizing for.
Ref:
[1] "Reversing CRC - Theory and Practice"
https://sar.informatik.hu-berlin.de/research/publications/SAR-PR-2006-05/SAR-PR-2006-05_.pdf
Robin Dapp [Thu, 26 Mar 2026 15:09:11 +0000 (16:09 +0100)]
RISC-V: Remove blanket else in riscv_hard_regno_mode_ok.
While looking at PR124439 I noticed that we have unreachable code in
riscv_hard_regno_mode_ok. Right now we just return false for registers
that don't match one of the first four if conditions.
Robin Dapp [Thu, 26 Mar 2026 15:19:43 +0000 (16:19 +0100)]
RISC-V: Fix format specifier.
Right now we get
../../gcc/config/riscv/riscv.cc: In function ‘bool riscv_check_target_clone_version(string_slice, location_t*)’:
../../gcc/config/riscv/riscv.cc:15078:17: warning: unknown conversion type character ‘B’ in format [-Wformat=]
15078 | "invalid version %qB for %<target_clones%> attribute",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../gcc/config/riscv/riscv.cc:15078:17: warning: too many arguments for format [-Wformat-extra-args]
with a GCC 15 host compiler.
This patch replaces %qB with $<%.*s%>.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_check_target_clone_version): Fix
format specifier.
Tomasz Kamiński [Mon, 18 May 2026 07:45:46 +0000 (09:45 +0200)]
libstdc++: Make is_exhaustive const for layout_(left/right)_padded
This is specified as const in the standard, and required to be const-callable
per layout mapping requirement. This made calls to is_exhaustive on mdspan
with such layout ill-formed.
libstdc++-v3/ChangeLog:
* include/std/mdspan (layout_left_padded::is_exhaustive)
(layout_righ_padded::is_exhaustive): Mark as const.
* testsuite/23_containers/mdspan/layouts/mapping.cc: Test noexcept and
const-invocability for is_exhaustive, is_strided, and is_unique.
* testsuite/23_containers/mdspan/layouts/padded.cc: Test is_exhaustive on
const mapping..
* testsuite/23_containers/mdspan/layouts/stride.cc: Likewise.
* testsuite/23_containers/mdspan/mdspan.cc: Checks const-invocability
for is_exhaustive, is_strided, is_unique.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com> Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
Jakub Jelinek [Mon, 18 May 2026 07:41:59 +0000 (09:41 +0200)]
i386: Implement bitreverse<mode>2 optab for GFNI [PR50481]
The following patch implements the bitreverse<mode>2 optab for
-mgfni -msse2 (SSE2 because apparently -mgfni doesn't imply -msse nor
-msse2).
This is done by using gf2p8affineqb insn with a special constant
which reverses bits in each byte, and for modes wider than QImode
also by doing a byteswap afterwards.
With -m64 it emits
.LC0:
.byte 1, 2, 4, 8, 16, 32, 64, -128
.byte 1, 2, 4, 8, 16, 32, 64, -128
and
movd %edi, %xmm0
gf2p8affineqb $0, .LC0(%rip), %xmm0
movd %xmm0, %eax
for __builtin_bitreverse8,
movd %edi, %xmm0
gf2p8affineqb $0, .LC0(%rip), %xmm0
movd %xmm0, %eax
rolw $8, %ax
for __builtin_bitreverse16,
movd %edi, %xmm0
gf2p8affineqb $0, .LC0(%rip), %xmm0
movd %xmm0, %eax
bswap %eax
for __builtin_bitreverse32,
movq %rdi, %xmm0
gf2p8affineqb $0, .LC0(%rip), %xmm0
movq %xmm0, %rax
bswap %rax
for __builtin_bitreverse64, and
movq %rdi, %xmm0
pinsrq $1, %rsi, %xmm0
gf2p8affineqb $0, .LC0(%rip), %xmm0
movq %xmm0, %rax
pextrq $1, %xmm0, %rdx
bswap %rax
bswap %rdx
xchgq %rdx, %rax
for __builtin_bitreverse128 (only the xchgq is unnecessary
and surprising, some RA issue).
2026-05-18 Jakub Jelinek <jakub@redhat.com>
PR target/50481
* config/i386/i386-protos.h (ix86_expand_gfni_bitreverse): Declare.
* config/i386/i386-expand.cc (ix86_expand_gfni_bitreverse): New
function.
* config/i386/i386.md (bitreverse<mode>2): New expander.
* gcc.target/i386/gfni-builtin-bitreverse-1.c: New test.
Tomasz Kamiński [Wed, 13 May 2026 07:17:47 +0000 (09:17 +0200)]
libstdc++: Use on_month_day istream operator in ZoneInfo parsing. [PR124852]
This patch changes ZoneInfo parsing, to use operator>> for on_month_day
directly, and removes on_day tag. The operator>>(istream&, on_month_day)
is updated to not override on.month if the MONTH component is not present,
and set failbit instead. This allows to use in >> on >> time, to parse
MONTH DAY TIME.
We also handle failure to parse day number N for Www>=N or Www<=N
productions, by leaving the day part of input unchanged and setting
failbit.
PR libstdc++/124852
libstdc++-v3/ChangeLog:
* src/c++20/tzdb.cc (on_month_day::on_day_t, on_month_day::on_day):
Remove.
(operator>>(istream&, on_month_day::day_t&)): Inlined into...
(operator>>(istream&, on_month_day)): Inlined on_month_day::on_day.
Avoid modifying on.month if MONTH is not present. Report failure
on failure to parse day for LessEq / GreaterEq.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com> Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
Andrew Pinski [Sat, 16 May 2026 23:17:01 +0000 (16:17 -0700)]
uncprop: small compile time optimization with switches
In the process of converting gswitch away from CASE_LABEL_EXPR,
I found a place in uncprop (like the case in dom) where we store
the whole CASE_LABEL_EXPR. This place only needed to store the value
of the case rather than the whole case expression. This does that
small optimization and adds a few comments for the next person
to understand what is going on here. It was not obvious at my
first read of the code what it was doing or what error_mark
was being used for.
Bootstrapped and tested on x86_64-linux-gnu.
gcc/ChangeLog:
* tree-ssa-uncprop.cc (associate_equivalences_with_edges): For switches
info only store the case low value to be recorded as
the only value. Add comments.
Signed-off-by: Andrew Pinski <andrew.pinski@oss.qualcomm.com>
Andrew Pinski [Fri, 15 May 2026 21:40:52 +0000 (14:40 -0700)]
dom: small compile time optimization with switches
In the process of converting gswitch away from CASE_LABEL_EXPR,
I found a place in dom where we store the whole CASE_LABEL_EXPR.
This place only needed to store the value of the case rather than
the whole case expression. This does that small optimization
and adds a few comments for the next person to understand what
is going on here. It was not obvious at my first read of the code
what it was doing or what error_mark was being used for.
Bootstrapped and tested on x86_64-linux-gnu.
gcc/ChangeLog:
* tree-ssa-dom.cc (record_edge_info): For switches
info only store the case low value to be recorded as
the only value. Add comments.
Signed-off-by: Andrew Pinski <andrew.pinski@oss.qualcomm.com>
projects / thirdparty / gcc.git / log
