Andrew Pinski [Thu, 9 Jan 2025 20:53:27 +0000 (12:53 -0800)]
Add assert to array_slice::begin/end
So while debugging PR 118320, I found it was useful to have
an assert inside array_slice::begin/end that the array slice isvalid
rather than getting an segfault. This adds an assert that is only
enabled for checking.
OK? Bootstrapped and tested on x86_64-linux-gnu.
gcc/ChangeLog:
* vec.h (array_slice::begin): Assert that the
slice is valid.
(array_slice::end): Likewise.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
/vol/gcc/src/hg/master/cobol/libgcobol/intrinsic.cc: In function ‘void
__gg__formatted_current_date(cblc_field_t*, cblc_field_t*, std::size_t,
std::size_t)’:
/vol/gcc/src/hg/master/cobol/libgcobol/intrinsic.cc:1480:6: error: ‘struct
std::tm’ has no member named ‘tm_zone’; did you mean ‘tm_mon’?
1480 | tm.tm_zone = "GMT";
| ^~~~~~~
| tm_mon
struct tm.tm_zone is new in POSIX.1-2024, thus cannot be assumed to be
present universally.
This patch checks for its presence and guards the use accordingly.
Bootstrapped without regressions on amd64-pc-solaris2.11,
sparcv9-sun-solaris2.11, and x86_64-pc-solaris2.11.
Thomas Schwinge [Sat, 19 Apr 2025 13:49:34 +0000 (15:49 +0200)]
Disable parallel testing for 'rust/compile/nr2/compile.exp' [PR119508]
..., using the standard idiom. This '*.exp' file doesn't adhere to the
parallel testing protocol as defined in 'gcc/testsuite/lib/gcc-defs.exp'.
This also restores proper behavior for '*.exp' files executing after (!) this
one, which erroneously caused hundreds or even thousands of individual test
cases get duplicated vs. skipped, randomly, depending on the '-jN' level.
Kaiweng's patch to stop freeing riscv_arch_string was correct, but incomplete
as there's another path that was freeing that node, which is just plain wrong
for a node allocated by the GC system.
This patch removes that call to free() which fixes the test. I've spun it in
my tester and will obviously wait for the pre-commit system to render a verdict
before moving forward.
PR target/119865
gcc/
* config/riscv/riscv.cc (parse_features_for_version): Do not
explicitly free the architecture string.
Jeff Law [Sat, 19 Apr 2025 18:30:42 +0000 (12:30 -0600)]
[RISC-V][PR target/118410] Improve code generation for some logical ops
I'm posting this on behalf of Shreya Munnangi who is working as an intern with
me. I've got her digging into prerequisites for removing mvconst_internal and
would prefer she focus on that rather than our patch process at this time.
--
We can use the orn, xnor, andn instructions on RISC-V to improve the code
generated logical operations when one operand is a constant C where
synthesizing ~C is cheaper than synthesizing C.
This is going to be an N -> N - 1 splitter rather than a define_insn_and_split.
A define_insn_and_split can obviously work, but has multiple undesirable
effects in general.
As a result of implementing as a simple define_split we're not supporting AND
at this time. We need to clean up the mvconst_internal situation first after
which supporting AND is trivial.
This has been tested in Ventana's CI system as well as my tester. Obviously
we'll wait for the pre-commit tester to run before moving forward.
PR target/118410
gcc/
* config/riscv/bitmanip.md (logical with constant argument): New
splitter for cases where synthesizing ~C is cheaper than synthesizing
the original constant C.
gcc/testsuite/
* gcc.target/riscv/pr118410-1.c: New test.
* gcc.target/riscv/pr118410-2.c: Likewise.
Jan Hubicka [Sat, 19 Apr 2025 16:51:27 +0000 (18:51 +0200)]
Add tables for SSE fp conversion costs
as disucssed, I will proceed adding costs for common SSE operations which are
currently globbed into addss cost, so we do not need to set it incorrectly for
znver5. Looking through the stats, there are quite few missing cases, so I am
starting with those that I think are more common. I plan to do it in smaller
steps so individual changes gets benchmarked by LNT and also can be bisected
to.
This patch adds costs for various SSE and AVX FP->FP conversions (extensions and
truncations). Looking through Agner Fog's tables, these are bit assymetric so I
added cost for CVTSS2SD which is also used for CVTSD2SS, CVTPS2PD and CVTPD2PS,
cost for 256bit VCVTPS2PS (also used for oposite direction) and cost for 512bit
one.
I plan to add int->int conversions next and then int->fp & fp->int which are
more tricky since they may bundle inter-unit move.
I also noticed that size tables are wrong for all SSE instructions so I updated
them. With some love I think vectorization can work as size optimization, too,
but we need more work on that.
Those values I can find in Agner Fog tables are taken from there, other are guesses
(especially for yongfeng_cost and shijidadao_cost).
gcc/ChangeLog:
* config/i386/i386.cc (vec_fp_conversion_cost): New function.
(ix86_rtx_costs): Use it for SSE/AVX FP conversoins.
(ix86_builtin_vectorization_cost): Fix indentation;
and use vec_fp_conversion_cost in vec_promote_demote.
(fp_conversion_stmt_cost): New function.
(ix86_vector_costs::add_stmt_cost): Use it to cost NOP_EXPR
and vec_promote_demote.
* config/i386/i386.h (struct processor_costs):
* config/i386/x86-tune-costs.h (struct processor_costs):
Andrew Pinski [Sat, 19 Apr 2025 03:28:40 +0000 (20:28 -0700)]
Fix pr118947-1.c and pr78408-3.c on targets where 32 bytes memcpy uses a vector
The problem here is on targets where a 32byte memcpy will use an integral (vector) type
to do the copy and the code will be optimized a different way than expected. This changes
the testcase instead to use a size of 1025 to make sure there is no target that will use an
integral (vector) type for the memcpy and be optimized via the method that was just added.
Pushed as obvious after a test run.
gcc/testsuite/ChangeLog:
* gcc.dg/pr118947-1.c: Use 1025 as the size of the buf.
* gcc.dg/pr78408-3.c: Likewise.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
Andrew Pinski [Mon, 20 Jan 2025 23:24:39 +0000 (15:24 -0800)]
combine: Better split point for `(and (not X))` [PR111949]
In a similar way find_split_point handles `a+b*C`, this adds
the split point for `~a & b`. This allows for better instruction
selection when the target has this instruction (aarch64, arm and x86_64
are examples which have this).
Built and tested for aarch64-linux-gnu.
PR rtl-optimization/111949
gcc/ChangeLog:
* combine.cc (find_split_point): Add a split point
for `(and (not X) Y)` if not in the outer set already.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/bic-1.c: New test.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
Jason Merrill [Mon, 3 Feb 2025 15:35:33 +0000 (10:35 -0500)]
c++: minor EXPR_STMT cleanup
I think it was around PR118574 that I noticed a few cases where we were
unnecessarily wrapping a statement tree in a further EXPR_STMT. Let's avoid
that and also use finish_expr_stmt in a few places in the coroutines code
that were building EXPR_STMT directly.
gcc/cp/ChangeLog:
* coroutines.cc (coro_build_expr_stmt)
(coro_build_cvt_void_expr_stmt): Remove.
(build_actor_fn): Use finish_expr_stmt.
* semantics.cc (finish_expr_stmt): Avoid wrapping statement in
EXPR_STMT.
(finish_stmt_expr_expr): Add comment.
Alpha: Fix base block alignment calculation regression
In determination of base block alignment we only examine a COMPONENT_REF
tree node at hand without ever checking if its ultimate alignment has
been reduced by the combined offset going back to the outermost object.
Consequently cases have been observed where quadword accesses have been
produced for a memory location referring a nested struct member only
aligned to the longword boundary, causing emulation to trigger.
Address this issue by recursing into COMPONENT_REF tree nodes until the
outermost one has been reached, which is supposed to be a MEM_REF one,
accumulating the offset as we go, fixing a commit e0dae4da4c45 ("Alpha:
Also use tree information to get base block alignment") regression.
Bail out and refrain from using tree information for alignment if we end
up at something different or we are unable to calculate the offset at
any point.
gcc/
* config/alpha/alpha.cc
(alpha_get_mem_rtx_alignment_and_offset): Recurse into
COMPONENT_REF nodes.
gcc/testsuite/
* gcc.target/alpha/memcpy-nested-offset-long.c: New file.
* gcc.target/alpha/memcpy-nested-offset-quad.c: New file.
François Dumont [Tue, 8 Apr 2025 17:35:28 +0000 (19:35 +0200)]
libstdc++: Add _GLIBCXX_DEBUG checks on unordered container local_iterator
Complete tests on _GLIBCXX_DEBUG checks in include/debug/safe_local_iterator.h.
Fix several tests not testing the container corresponding to their location in the
testsuite directory.
libstdc++-v3/ChangeLog:
* testsuite/util/debug/unordered_checks.h (fill_container): New helper method.
(use_erased_local_iterator, invalid_local_iterator_pre_increment)
(invalid_local_iterator_post_increment, invalid_local_iterator_compare)
(invalid_local_iterator_range): Use latter.
(fill_and_get_local_iterator): New, use fill_container.
(use_invalid_local_iterator): Use latter.
(invalid_local_iterator_arrow_operator): New test function.
(invalid_local_iterator_copy_instantiation): New test function.
(invalid_local_iterator_move_instantiation): New test function.
(invalid_local_iterator_copy_assignment): New test function.
(invalid_local_iterator_move_assignment): New test function.
(invalid_local_iterator_const_conversion): New test function.
* testsuite/23_containers/unordered_map/debug/invalid_local_iterator_arrow_operator_neg.cc:
New test case.
* testsuite/23_containers/unordered_map/debug/invalid_local_iterator_const_conversion_neg.cc:
New test case.
* testsuite/23_containers/unordered_map/debug/invalid_local_iterator_copy_assignment_neg.cc:
New test case.
* testsuite/23_containers/unordered_map/debug/invalid_local_iterator_copy_construction_neg.cc:
New test case.
* testsuite/23_containers/unordered_map/debug/invalid_local_iterator_move_assignment_neg.cc:
New test case.
* testsuite/23_containers/unordered_map/debug/invalid_local_iterator_move_construction_neg.cc:
New test case.
* testsuite/23_containers/unordered_map/debug/max_load_factor_neg.cc: Test unordered_map.
* testsuite/23_containers/unordered_multimap/debug/begin2_neg.cc: Test unordered_multimap.
* testsuite/23_containers/unordered_multimap/debug/bucket_size_neg.cc: Likewise.
* testsuite/23_containers/unordered_multimap/debug/cbegin_neg.cc: Likewise.
* testsuite/23_containers/unordered_multimap/debug/cend_neg.cc: Likewise.
* testsuite/23_containers/unordered_multimap/debug/end1_neg.cc: Likewise.
* testsuite/23_containers/unordered_multimap/debug/end2_neg.cc: Likewise.
* testsuite/23_containers/unordered_multimap/debug/invalid_local_iterator_arrow_operator_neg.cc:
New test case.
* testsuite/23_containers/unordered_multimap/debug/invalid_local_iterator_const_conversion_neg.cc:
New test case.
* testsuite/23_containers/unordered_multimap/debug/invalid_local_iterator_copy_assignment_neg.cc:
New test case.
* testsuite/23_containers/unordered_multimap/debug/invalid_local_iterator_copy_construction_neg.cc:
New test case.
* testsuite/23_containers/unordered_multimap/debug/invalid_local_iterator_move_assignment_neg.cc:
New test case.
* testsuite/23_containers/unordered_multimap/debug/invalid_local_iterator_move_construction_neg.cc:
New test case.
* testsuite/23_containers/unordered_multimap/debug/max_load_factor_neg.cc:
Test unordered_multimap.
* testsuite/23_containers/unordered_multiset/debug/invalid_local_iterator_arrow_operator_neg.cc:
New test case.
* testsuite/23_containers/unordered_multiset/debug/invalid_local_iterator_const_conversion_neg.cc:
New test case.
* testsuite/23_containers/unordered_multiset/debug/invalid_local_iterator_copy_assignment_neg.cc:
New test case.
* testsuite/23_containers/unordered_multiset/debug/invalid_local_iterator_copy_construction_neg.cc:
New test case.
* testsuite/23_containers/unordered_multiset/debug/invalid_local_iterator_move_assignment_neg.cc:
New test case.
* testsuite/23_containers/unordered_multiset/debug/invalid_local_iterator_move_construction_neg.cc:
New test case.
* testsuite/23_containers/unordered_set/debug/invalid_local_iterator_arrow_operator_neg.cc:
New test case.
* testsuite/23_containers/unordered_set/debug/invalid_local_iterator_const_conversion_neg.cc:
New test case.
* testsuite/23_containers/unordered_set/debug/invalid_local_iterator_copy_assignment_neg.cc:
New test case.
* testsuite/23_containers/unordered_set/debug/invalid_local_iterator_copy_construction_neg.cc:
New test case.
* testsuite/23_containers/unordered_set/debug/invalid_local_iterator_move_assignment_neg.cc:
New test case.
* testsuite/23_containers/unordered_set/debug/invalid_local_iterator_move_construction_neg.cc:
New test case.
Jeff Law [Fri, 18 Apr 2025 18:19:30 +0000 (12:19 -0600)]
[RISC-V] Fix missed bext discovery
RISC-V has the ability to extract a single bit out of a register from a fixed
or variable position.
While looking at 502.gcc a little while ago I realize that we failed to use
bext inside bitmap_bit_p for its return value.
The core "problem" is that the RISC-V does not define SHIFT_COUNT_TRUNCATED
(for good reasons). As a result the target is largely responsible for handling
elimination of shift count/bit position masking.
There's a follow-up patch I've been working on with an intern to improve
detection of bext in more cases. This one stands independently though and is
probably the most important of the missed cases.
Will push to the trunk assuming pre-commit testing is green. It's already been
through my tester as well as Ventana's internal testing.
gcc
* config/riscv/bitmanip.md (*bext<mode>_mask_pos): New pattern
for extracting a single bit at masked bit position.
Andrew Pinski [Tue, 8 Apr 2025 00:57:07 +0000 (17:57 -0700)]
DSE: Trim stores of 0 like triming stores of {} [PR87901]
This is the second part of the PR which comes from transformation
of memset into either stores of 0 (via an integral type) or stores
of {}. We already handle stores of `{}`, this just extends that to
handle of the constant 0 and treat it similarly.
PR tree-optimization/87901
gcc/ChangeLog:
* tree-ssa-dse.cc (maybe_trim_constructor_store): Add was_integer_cst argument.
Check for was_integer_cst instead of `{}` when was_integer_cst is true.
(maybe_trim_partially_dead_store): Handle INTEGER_CST stores of 0 as stores of `{}`.
Udpate call to maybe_trim_constructor_store for CONSTRUCTOR.
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/ssa-dse-53.c: New test.
* gcc.dg/tree-ssa/ssa-dse-54.c: New test.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
Andrew Pinski [Tue, 8 Apr 2025 00:06:17 +0000 (17:06 -0700)]
DSE: Support triming of some more memset [PR87901]
DSE has support for trimming memset (and memset like) statements.
In this case we have `MEM <unsigned char[17]> [(char * {ref-all})&z] = {};` in
the IR and when we go to trim it, we call build_fold_addr_expr which leaves around
a cast from one pointer type to another. This is due to build_fold_addr_expr
being generic but in gimple you don't need these casts.
PR tree-optimization/87901
gcc/ChangeLog:
* tree-ssa-dse.cc (maybe_trim_constructor_store): Strip over useless type
conversions after taking the address of the MEM_REF.
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/ssa-dse-52.c: New test.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
Andrew Pinski [Fri, 14 Feb 2025 04:23:48 +0000 (20:23 -0800)]
gimple: Canonical order for invariants [PR118902]
So unlike constants, address invariants are currently put first if
used with a SSA NAME.
It would be better if address invariants are consistent with constants
and this patch changes that.
gcc.dg/tree-ssa/pr118902-1.c is an example where this canonicalization
can help. In it if `p` variable was a global variable, FRE (VN) would have figured
it out that `a` could never be equal to `&p` inside the loop. But without the
canonicalization we end up with `&p == a.0_1` which VN does try to handle for conditional
VN.
Bootstrapped and tested on x86_64.
PR tree-optimization/118902
gcc/ChangeLog:
* fold-const.cc (tree_swap_operands_p): Place invariants in the first operand
if not used with constants.
gcc/testsuite/ChangeLog:
* gcc.dg/tree-ssa/pr118902-1.c: New test.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
Andrew Pinski [Mon, 24 Feb 2025 20:33:32 +0000 (12:33 -0800)]
gimple-fold: Improve optimize_memcpy_to_memset by walking back until aliasing says the ref is a may clobber. [PR118947]
The case here is we have:
```
char buf[32] = {};
void* ret = aaa();
__builtin_memcpy(ret, buf, 32);
```
And buf does not escape. But we don't prop the zeroing from buf to the memcpy statement
because optimize_memcpy_to_memset only looks back one statement. This can be fixed to look back
until we get an statement that may clobber the reference. If we get a phi node, then we don't do
anything.
Bootstrapped and tested on x86_64-linux-gnu.
PR tree-optimization/118947
gcc/ChangeLog:
* gimple-fold.cc (optimize_memcpy_to_memset): Walk back until we get a
statement that may clobber the read.
gcc/testsuite/ChangeLog:
* gcc.dg/pr118947-1.c: New test.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
Andrew Pinski [Fri, 21 Feb 2025 00:09:05 +0000 (16:09 -0800)]
gimple-fold: Improve optimize_memcpy_to_memset to handle STRING_CST [PR78408]
While looking into PR 118947, I noticed that optimize_memcpy_to_memset didn't
handle STRING_CST which are also used for a memset of 0 but for char arrays.
This fixes that and improves optimize_memcpy_to_memset to handle that case.
This fixes part of PR 118947 but not the whole thing; we still need to skip over
vdefs in some cases.
Richard Braun [Fri, 18 Apr 2025 15:26:59 +0000 (09:26 -0600)]
[PATCH] c6x: Fix EHTYPE relocations
R_C6000_EHTYPE relocations are implemented as GOT-indirect relocations,
but, as specified by the C6000 EABI (SPRAB89A), 13.5.1 Relocation Types,
they are a special case of SBR (static base relocation).
gcc/
* config/c6x/c6x.h (ASM_PREFERRED_EH_DATA_FORMAT): Remove the
DW_EH_PE_indirect flag.
Dimitar Dimitrov [Wed, 29 Jan 2025 17:43:15 +0000 (19:43 +0200)]
testsuite: Use int size instead of alignment for pr116357.c
The test case assumes that alignof(int)=sizeof(int). But for some
targets this is not valid. For example, for PRU target,
alignof(int)=1 but sizeof(int)=4.
Fix the test case to align to twice the size of int, as the expected
dg-error messages suggest.
This patch fixes the test failures for PRU target.
gcc/testsuite/ChangeLog:
* gcc.dg/pr116357.c: Use sizeof(int) instead of alignof(int).
[PATCH] [RISC-V] Tune for removal unnecessary sext in builtin overflows [PR108016]
It fixes one of the PR108016 mis-optimization.
The patch adjusts expanding for __builtin_add/sub_overflow() on RV64 targets
to avoid unnecessary sext.w instructions.
It replaces expanded for ADD/SUB_OVERFLOW code:
r141:SI=r139:DI#0+r140:DI#0 .. r143:DI=sign_extend(r141:SI)
to the followong kind of chain ->
r143:DI=sign_extend(r139:DI#0+r140:DI#0) .. r141:SI=r143:DI#0
so that sign_extend(a:SI+b:SI) to be emitted as addw (or subw) instruction,
while output r141:SI register will be placed at the end of chain without
extra dependencies, and thus could be easily optimized-out by further pipeline.
kelefth [Thu, 13 Mar 2025 10:49:39 +0000 (11:49 +0100)]
avoid-store-forwarding: Fix reg init on load-elimination [PR119160]
In the case that we are eliminating the load instruction, we use zero_extend
for the initialization of the base register for the zero-offset store.
This causes issues when the store and the load use the same mode,
as we are trying to generate a zero_extend with the same inner and
outer modes.
This patch fixes the issue by zero-extending the value stored in the
base register only when the load's mode is wider than the store's mode.
PR rtl-optimization/119160
gcc/ChangeLog:
* avoid-store-forwarding.cc (process_store_forwarding):
Zero-extend the value stored in the base register, in case
of load-elimination, only when the mode of the destination
is wider.
kelefth [Thu, 13 Mar 2025 14:42:48 +0000 (15:42 +0100)]
doc: Clarify REG_EH_REGION note usage
The documentation for the REG_EH_REGION could easily be read
(especially by non-native speakers) to indicate that it should be
attached to insn at the destination of an excpetion edge. Despite the
original text saying that the note "specifies the destination," it is
actually always attached to the source instruction.
This updates the documentation to make it clear that the REG_EH_REGION
note is always attached to instructions originating an exception edge
and that the value of the note specifies where the exception edge
leads to.
Co-Developed-by: Philipp Tomsich <philipp.tomsich@vrull.eu>
gcc/ChangeLog:
* doc/cfg.texi: Update the exception handling section for the
REG_EH_REGION notes to make it clear that the note is attached
to the instruction throwing the exception.
[PATCH] RISC-V: Do not free a riscv_arch_string when handling target-arch attribute
The build_target_option_node() function may return a cached node when
fndecl having the same effective global_options. Therefore, freeing
memory used in target nodes can lead to a use-after-free issue, as a
target node may be shared by multiple fndecl.
This issue occurs in gcc.target/riscv/target-attr-16.c, where all
functions have the same march, but the last function tries to free its
old x_riscv_arch_string (which is shared) when processing the second
target attribute.However, the behavior of this issue depends on how the
OS handles malloc. It's very likely that xstrdup returns the old address
just freed, coincidentally hiding the issue. We can verify the issue by
forcing xstrdup to return a new address, e.g.,
- if (opts->x_riscv_arch_string != default_opts->x_riscv_arch_string)
- free (CONST_CAST (void *, (const void *) opts->x_riscv_arch_string));
+ // Force it to use a new address, NFCI
+ const char *tmp = opts->x_riscv_arch_string;
opts->x_riscv_arch_string = xstrdup (local_arch_str);
Jason Merrill [Wed, 16 Apr 2025 20:02:09 +0000 (16:02 -0400)]
c++: constexpr virtual base diagnostic
I thought this diagnostic could be clearer that the problem is the
combination of virtual bases and constexpr constructor, not just complain
that the class has virtual bases without context.
Jason Merrill [Sun, 19 Jan 2025 10:15:01 +0000 (05:15 -0500)]
c++: vec_safe_reserve usage tweaks
A couple of cleanups from noticing that the semantics of
std::vector<T>::reserve() (request the new minimum allocation) differ from
the GCC vec<...>::reserve() (request a minimum number of slots available).
In preserve_state, we were tripling the size of the vec when doubling it is
more than enough.
In get_tinfo_desc we were using vec_safe_reserve properly, but it's
simpler to use vec_safe_grow_cleared.
Jason Merrill [Sat, 5 Apr 2025 03:27:50 +0000 (23:27 -0400)]
c++: add assert to cp_make_fname_decl
In the PR118629 testcase, pushdecl_outermost_localscope was failing and
returning error_mark_node without ever actually giving an error; in addition
to my earlier fix for the failure, make sure failures aren't silent.
Sam James [Mon, 24 Mar 2025 04:32:47 +0000 (04:32 +0000)]
doc: say "compatible types" for -fstrict-aliasing
Include the term used in the standard to ease further research for users,
and while at it, rephrase the description of the rule entirely using
Alexander Monakov's suggestion: it was previously wrong (and imprecise) as
"the same address" may well be re-used later on, and the issue is the
access via an expression of the wrong type.
gcc/ChangeLog:
* doc/invoke.texi: Use "compatible types" term. Rephrase to be
more precise (and correct).
Jakub Jelinek [Thu, 17 Apr 2025 10:50:35 +0000 (12:50 +0200)]
Update crontab and git_update_version.py
2025-04-17 Jakub Jelinek <jakub@redhat.com>
maintainer-scripts/
* crontab: Snapshots from trunk are now GCC 16 related.
Add GCC 15 snapshots from the respective branch.
contrib/
* gcc-changelog/git_update_version.py (active_refs): Add
releases/gcc-15.
Jakub Jelinek [Thu, 17 Apr 2025 10:14:15 +0000 (12:14 +0200)]
libgomp: Don't test ompx::allocator::gnu_pinned_mem on non-linux targets.
The libgomp.c/alloc-pinned*.c test have
/* { dg-skip-if "Pinning not implemented on this host" { ! *-*-linux-gnu* } } */
so they are only run on Linux targets right now. Duplicating the tests or
reworking them into headers looked like too much work for me right now this
late in stage4, so I've just #ifdefed the uses at least for now.
Here the basic blocks are rotated and a not is generated.
But the generated not is unmasked (or predicated over an ALL true mask in this
case). This has the unintended side-effect of flipping the results of the
inactive lanes (which were zero'd by the cmpgt) into -1. Which then incorrectly
causes us to not take the branch to .L2.
This is happening because we're not comparing against the right value for the
forall case. This patch gets rid of the forall case by rewriting the
if(all(mask)) into if (!all(mask)) which is the same as if (any(~mask)) by
negating the masks and flipping the branches.
1. For unmasked loops we simply reduce the ~mask.
2. For masked loops we reduce (~mask & loop_mask) which is the same as
doing (mask & loop_mask) ^ loop_mask.
Jonathan Wakely [Wed, 16 Apr 2025 10:44:46 +0000 (11:44 +0100)]
libstdc++: Do not use 'not' alternative token in <format>
This fixes:
FAIL: 17_intro/headers/c++1998/operator_names.cc -std=gnu++23 (test for excess errors)
FAIL: 17_intro/headers/c++1998/operator_names.cc -std=gnu++26 (test for excess errors)
The purpose of 'not defined<format_kind<R>>' is to be ill-formed (as
required by [format.range.fmtkind]) and to give an error that includes
the string "not defined<format_kind<R>>". That was intended to tell you
that format_kind<R> is not defined, just like it says!
But user code can use -fno-operator-names so we can't use 'not' here,
and "! defined" in the diagnostic doesn't seem as user-friendly. It also
raises questions about whether it was intended to be the preprocessor
token 'defined' (it's not) or where 'defined' is defined (it's not).
Replace it with __primary_template_not_defined<format_kind<R>> and a
comment, which seems to give a fairly clear diagnostic with both GCC and
Clang. The diagnostic now looks like:
.../include/c++/15.0.1/format:5165:7: error: use of 'std::format_kind<int>' before deduction of 'auto'
5165 | format_kind<_Rg> // you can specialize this for non-const input ranges
| ^~~~~~~~~~~~~~~~
.../include/c++/15.0.1/format:5164:35: error: '__primary_template_not_defined' was not declared in this scope
5164 | __primary_template_not_defined(
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
5165 | format_kind<_Rg> // you can specialize this for non-const input ranges
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
5166 | );
| ~
libstdc++-v3/ChangeLog:
* include/std/format (format_kind): Do not use 'not'
alternative token to make the primary template ill-formed. Use
the undeclared identifier __primary_template_not_defined and a
comment that will appear in diagnostics.
* testsuite/std/format/ranges/format_kind_neg.cc: New test.
Jakub Jelinek [Thu, 17 Apr 2025 08:57:18 +0000 (10:57 +0200)]
s390: Use match_scratch instead of scratch in define_split [PR119834]
The following testcase ICEs since r15-1579 (addition of late combiner),
because *clrmem_short can't be split.
The problem is that the define_insn uses
(use (match_operand 1 "nonmemory_operand" "n,a,a,a"))
(use (match_operand 2 "immediate_operand" "X,R,X,X"))
(clobber (match_scratch:P 3 "=X,X,X,&a"))
and define_split assumed that if operands[1] is const_int_operand,
match_scratch will be always scratch, and it will be reg only if
it was the last alternative where operands[1] is a reg.
The pattern doesn't guarantee it though, of course RA will not try to
uselessly assign a reg there if it is not needed, but during RA
on the testcase below we match the last alternative, but then comes
late combiner and propagates const_int 3 into operands[1]. And that
matches fine, match_scratch matches either scratch or reg and the constraint
in that case is X for the first variant, so still just fine. But we won't
split that because the splitters only expect scratch.
The following patch fixes it by using match_scratch instead of scratch,
so that it accepts either.
2025-04-17 Jakub Jelinek <jakub@redhat.com>
PR target/119834
* config/s390/s390.md (define_split after *cpymem_short): Use
(clobber (match_scratch N)) instead of (clobber (scratch)). Use
(match_dup 4) and operands[4] instead of (match_dup 3) and operands[3]
in the last of those.
(define_split after *clrmem_short): Use (clobber (match_scratch N))
instead of (clobber (scratch)).
(define_split after *cmpmem_short): Likewise.
Tomasz Kamiński [Wed, 16 Apr 2025 13:28:46 +0000 (15:28 +0200)]
libstdc++: Remove dead code in range_formatter::format [PR109162]
Because the _M_format(__rg, __fc) were placed outside of if constexpr,
these method and its children where instantiated, even if
_M_format<const _Range> could be used.
To simplify the if constexpr chain, we introduce a __simply_formattable_range
(name based on simple-view) exposition only concept, that checks if range is
const and mutable formattable and uses same formatter specialization for
references in each case.
PR libstdc++/109162
libstdc++-v3/ChangeLog:
* include/std/format (__format::__simply_formattable_range): Define.
(range_formatter::format): Do not instantiate _M_format for mutable
_Rg if const _Rg can be used.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com> Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
libgomp.texi: For HIP interop, mention cpp defines to set
The HIP header files recognize the used compiler, defaulting to either AMD
or Nvidia/CUDA; thus, the alternative way of explicitly defining a macro is
less prominently documented. With GCC, the user has to define the
preprocessor macro manually. Hence, as a service to the user, mention
__HIP_PLATFORM_AMD__ and __HIP_PLATFORM_NVIDIA__ in the interop documentation,
even though it has only indirectly to do with GCC and its interop support.
Note to commit-log readers, only: For Fortran, the hipfort modules can be
used; when compiling the hipfort package (defaults to use gfortran), it
generates the module (*.mod) files in include/hipfort/{amdgcn,nvidia}/ such
that the choice is made by setting the respective include path.
libgomp/ChangeLog:
* libgomp.texi (gcn interop, nvptx interop): For HIP with C/C++, add
a note about setting a preprocessor define.
An infinite loop was introduced by a previous refactoring in the
semantic pass for DeclarationExp nodes. Ensure the loop properly
terminates and add tests cases.
combine: Correct comments about combine_validate_cost
Fix misleading comments. That function only determines whether
replacements cost more; it doesn't actually *validate* costs as being
cheaper.
For example, it returns true also if it for various reasons cannot
determine the costs, or if the new cost is the same, like when doing
an identity replacement. The code has been the same since r0-59417-g64b8935d4809f3.
* combine.cc: Correct comments about combine_validate_cost.
Jason Merrill [Tue, 31 Aug 2021 21:01:22 +0000 (17:01 -0400)]
c++: ill-formed constexpr function [PR113360]
If we already gave an error while parsing a function, we don't also need to
try to explain what's wrong with it when we later try to use it in a
constant-expression. In the new testcase explain_invalid_constexpr_fn
couldn't find anything still in the function to complain about, so it said
because: followed by nothing.
We still try to constant-evaluate it to reduce error cascades, but we
shouldn't complain if it doesn't work very well.
This flag is similar to CLASSTYPE_ERRONEOUS that I added a while back.
PR c++/113360
gcc/cp/ChangeLog:
* cp-tree.h (struct language_function): Add erroneous bit.
* constexpr.cc (explain_invalid_constexpr_fn): Return if set.
(cxx_eval_call_expression): Quiet if set.
* parser.cc (cp_parser_function_definition_after_declarator)
* pt.cc (instantiate_body): Set it.
Peter Bergner [Wed, 16 Apr 2025 21:48:59 +0000 (21:48 +0000)]
testsuite: Replace altivec vector attribute with generic equivalent [PR112822]
Usage of the altivec vector attribute requires use of the -maltivec option.
Replace with a generic equivalent which allows building the test case on
multiple other targets and non-altivec ppc cpus, but still diagnoses the
ICE on unfixed compilers.
2025-04-16 Peter Bergner <bergner@linux.ibm.com>
gcc/testsuite/
PR tree-optimization/112822
* g++.dg/pr112822.C: Replace altivec vector attribute with a generic
vector attribute.
Keith Packard [Wed, 16 Apr 2025 20:10:18 +0000 (14:10 -0600)]
[PATCH] rx: avoid adding setpsw for rx_cmpstrn when len is const
pattern using rx_cmpstrn is cmpstrsi for which len is a constant -1,
so we'll be moving the setpsw instructions from rx_cmpstrn to
cmpstrnsi as follows:
1. Adjust the predicate on the length operand from "register_operand"
to "nonmemory_operand". This will allow constants to appear here,
instead of having them already transferred into a register.
2. Check to see if the len value is constant, and then check if it is
actually zero. In that case, short-circuit the rest of the pattern
and set the result register to 0.
3. Emit 'setpsw c' and 'setpsw z' instructions when the len is not a
constant, in case it turns out to be zero at runtime.
4. Remove the two 'setpsw' instructions from rx_cmpstrn.
gcc/
* config/rx/rx.md (cmpstrnsi): Allow constant length. For
static length 0, just store 0 into the output register.
For dynamic zero, set C/Z appropriately.
(rxcmpstrn): No longer set C/Z.
Eric Botcazou [Wed, 16 Apr 2025 20:01:31 +0000 (22:01 +0200)]
Fix wrong optimization of conditional expression with enumeration type
This is a regression introduced on the mainline and 14 branch by:
https://gcc.gnu.org/pipermail/gcc-cvs/2023-October/391658.html
The change bypasses int_fits_type_p (essentially) to work around the
signedness constraints, but in doing so disregards the peculiarities
of boolean types whose precision is not 1 dealt with by the predicate,
leading to the creation of a problematic conversion here.
Fixed by special-casing boolean types whose precision is not 1, as done
in several other places.
gcc/
* tree-ssa-phiopt.cc (factor_out_conditional_operation): Do not
bypass the int_fits_type_p test for boolean types whose precision
is not 1.
gcc/testsuite/
* gnat.dg/opt105.adb: New test.
* gnat.dg/opt105_pkg.ads, gnat.dg/opt105_pkg.adb: New helper.
Since r12-5426 apply_late_template_attributes suppresses various global
state to avoid applying active pragmas to earlier declarations; we also
need to override target_option_current_node.
PR c++/114772
PR c++/101180
gcc/cp/ChangeLog:
* pt.cc (apply_late_template_attributes): Also override
target_option_current_node.
Jason Merrill [Wed, 16 Apr 2025 15:15:14 +0000 (11:15 -0400)]
c++: format attribute redeclaration [PR116954]
Here when merging the two decls, remove_contract_attributes loses
ATTR_IS_DEPENDENT on the format attribute, so apply_late_template_attributes
just returns, so the attribute doesn't get propagated to the type where the
warning looks for it.
Fixed by using copy_node instead of tree_cons to preserve flags.
PR c++/116954
gcc/cp/ChangeLog:
* contracts.cc (remove_contract_attributes): Preserve flags
on the attribute list.
i386: Enable -mnop-mcount for -fpic with PLTs [PR119386]
-mnop-mcount can be trivially enabled for -fPIC codegen as long as PLTs
are being used, given that the instruction encodings are identical, only
the target may resolve differently depending on how the linker decides
to incorporate the object file.
So relax the option check, and add a test to ensure that 5-byte NOPs are
emitted when -mnop-mcount is being used.
i386: Prefer PLT indirection for __fentry__ calls under -fPIC [PR119386]
Commit bde21de1205 ("i386: Honour -mdirect-extern-access when calling
__fentry__") updated the logic that emits mcount() / __fentry__() calls
into function prologues when profiling is enabled, to avoid GOT-based
indirect calls when a direct call would suffice.
There are two problems with that change:
- it relies on -mdirect-extern-access rather than -fno-plt to decide
whether or not a direct [PLT based] call is appropriate;
- for the PLT case, it falls through to x86_print_call_or_nop(), which
does not emit the @PLT suffix, resulting in the wrong relocation to be
used (R_X86_64_PC32 instead of R_X86_64_PLT32)
Fix this by testing flag_plt instead of ix86_direct_extern_access, and
updating x86_print_call_or_nop() to take flag_pic and flag_plt into
account. This also ensures that -mnop-mcount works as expected when
emitting the PLT based profiling calls.
While at it, fix the 32-bit logic as well, and issue a PLT call unless
PLTs are explicitly disabled.
PR target/119386
* config/i386/i386.cc (x86_print_call_or_nop): Add @PLT suffix
where appropriate.
(x86_function_profiler): Fall through to x86_print_call_or_nop()
for PIC codegen when flag_plt is set.
gcc/testsuite/ChangeLog:
PR target/119386
* gcc.target/i386/pr119386-1.c: New test.
* gcc.target/i386/pr119386-2.c: New test.
Doc: Add pointer to --help use to main entry for -Q option [PR90465]
-Q does something completely different in conjunction with --help than it
does otherwise; its main entry in the manual didn't mention that, nor did
-Q have an entry in the index for the --help usage.
gcc/ChangeLog
PR driver/90465
* doc/invoke.texi (Overall Options): Add a @cindex for -Q in
connection with --help=.
(Developer Options): Point at --help= documentation for the
other use of -Q.
Harald Anlauf [Tue, 15 Apr 2025 18:43:05 +0000 (20:43 +0200)]
Fortran: pure subroutine with pure procedure as dummy [PR106948]
PR fortran/106948
gcc/fortran/ChangeLog:
* resolve.cc (gfc_pure_function): If a function has been resolved,
but esym is not yet set, look at its attributes to see whether it
is pure or elemental.
Thomas Schwinge [Wed, 16 Apr 2025 14:52:08 +0000 (16:52 +0200)]
Remove 'ALWAYS_INLINE' workaround in 'libgomp.c++/target-exceptions-pr118794-1.C'
With commit ca9cffe737d20953082333dacebb65d4261e0d0c
"For nvptx offloading, make sure to emit C++ constructor, destructor aliases [PR97106]",
we're able to remove the 'ALWAYS_INLINE' workaround added in
commit fe283dba774be57b705a7a871b000d2894d2e553
"GCN, nvptx: Support '-mfake-exceptions', and use it for offloading compilation [PR118794]".
Jakub Jelinek [Wed, 16 Apr 2025 15:22:49 +0000 (17:22 +0200)]
libatomic: Fix up libat_{,un}lock_n for mingw [PR119796]
Here is just a port of the previously posted patch to mingw which
clearly has the same problems.
2025-04-16 Jakub Jelinek <jakub@redhat.com>
PR libgcc/101075
PR libgcc/119796
* config/mingw/lock.c (libat_lock_n, libat_unlock_n): Start with
computing how many locks will be needed and take into account
((uintptr_t)ptr % WATCH_SIZE). If some locks from the end of the
locks array and others from the start of it will be needed, first
lock the ones from the start followed by ones from the end.
Jakub Jelinek [Wed, 16 Apr 2025 15:21:39 +0000 (17:21 +0200)]
libatomic: Fix up libat_{,un}lock_n [PR119796]
As mentioned in the PR (and I think in PR101075 too), we can run into
deadlock with libat_lock_n calls with larger n.
As mentioned in PR66842, we use multiple locks (normally 64 mutexes
for each 64 byte cache line in 4KiB page) and currently can lock more
than one lock, in particular for n [0, 64] a single lock, for n [65, 128]
2 locks, for n [129, 192] 3 locks etc.
There are two problems with this:
1) we can deadlock if there is some wrap-around, because the locks are
acquired always in the order from addr_hash (ptr) up to
locks[NLOCKS-1].mutex and then if needed from locks[0].mutex onwards;
so if e.g. 2 threads perform libat_lock_n with n = 2048+64, in one
case at pointer starting at page boundary and in another case at
page boundary + 2048 bytes, the first thread can lock the first
32 mutexes, the second thread can lock the last 32 mutexes and
then first thread wait for the lock 32 held by second thread and
second thread wait for the lock 0 held by the first thread;
fixed below by always locking the locks in order of increasing
index, if there is a wrap-around, by locking in 2 loops, first
locking some locks at the start of the array and second at the
end of it
2) the number of locks seems to be determined solely depending on the
n value, I think that is wrong, we don't know the structure alignment
on the libatomic side, it could very well be 1 byte aligned struct,
and so how many cachelines are actually (partly or fully) occupied
by the atomic access depends not just on the size, but also on
ptr % WATCH_SIZE, e.g. 2 byte structure at address page_boundary+63
should IMHO lock 2 locks because it occupies the first and second
cacheline
Note, before this patch it locked exactly one lock for n = 0, while
with this patch it could lock either no locks at all (if it is at cacheline
boundary) or 1 (otherwise).
Dunno of libatomic APIs can be called for zero sizes and whether
we actually care that much how many mutexes are locked in that case,
because one can't actually read/write anything into zero sized memory.
If you think it is important, I could add else if (nlocks == 0) nlocks = 1;
in both spots.
2025-04-16 Jakub Jelinek <jakub@redhat.com>
PR libgcc/101075
PR libgcc/119796
* config/posix/lock.c (libat_lock_n, libat_unlock_n): Start with
computing how many locks will be needed and take into account
((uintptr_t)ptr % WATCH_SIZE). If some locks from the end of the
locks array and others from the start of it will be needed, first
lock the ones from the start followed by ones from the end.
Tomasz Kamiński [Wed, 16 Apr 2025 11:39:04 +0000 (13:39 +0200)]
libstdc++: Fix constification in range_formatter::format [PR109162]
The _Rg is deduced to lvalue reference for the lvalue arguments,
and in such case __format::__maybe_const_range<_Rg, _CharT> is always _Rg
(adding const to reference does not change behavior).
Now we correctly check if _Range = remove_reference_t<_Rg> is const
formattable range, furthermore as range_formatter<T> can only format
ranges of values of type (possibly const) _Tp, we additional check if the
remove_cvref_t<range_reference_t<const _Range>> is _Tp.
The range_reference_t<R> and range_reference_t<const R> have different
types (modulo remove_cvref_t) for std::vector<bool> (::reference and bool)
or flat_map<T, U> (pair<const T&, U&> and pair<const T&, const U&>).
PR libstdc++/109162
libstdc++-v3/ChangeLog:
* include/std/format (range_formatter::format): Format const range,
only if reference type is not changed.
* testsuite/std/format/ranges/formatter.cc: New tests.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com> Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
Tamar Christina [Wed, 16 Apr 2025 12:11:20 +0000 (13:11 +0100)]
middle-end: force AMDGCN test for vect-early-break_18.c to consistent architecture [PR119286]
The given test is intended to test vectorization of a strided access done by
having a step of > 1.
GCN target doesn't support load lanes, so the testcase is expected to fail,
other targets create a permuted load here which we then then reject.
However some GCN arch don't seem to support the permuted loads either, so the
vectorizer tries a gather/scatter. But the indices aren't supported by some
target, so instead the vectorizer scalarizes the loads.
I can't really test for which architecture is being used by the compiler, so
instead this updates the testcase to use one single architecture so we get a
consistent result.
gcc/testsuite/ChangeLog:
PR target/119286
* gcc.dg/vect/vect-early-break_18.c: Force -march=gfx908 for amdgcn.
Tamar Christina [Wed, 16 Apr 2025 12:09:05 +0000 (13:09 +0100)]
middle-end: Fix incorrect codegen with PFA and VLS [PR119351]
The following example:
#define N 512
#define START 2
#define END 505
int x[N] __attribute__((aligned(32)));
int __attribute__((noipa))
foo (void)
{
for (signed int i = START; i < END; ++i)
{
if (x[i] == 0)
return i;
}
return -1;
}
generates incorrect code with fixed length SVE because for early break we need
to know which value to start the scalar loop with if we take an early exit.
Historically this means that we take the first element of every induction.
this is because there's an assumption in place, that even with masked loops the
masks come from a whilel* instruction.
As such we reduce using a BIT_FIELD_REF <, 0>.
When PFA was added this assumption was correct for non-masked loop, however we
assumed that PFA for VLA wouldn't work for now, and disabled it using the
alignment requirement checks. We also expected VLS to PFA using scalar loops.
However as this PR shows, for VLS the vectorizer can, and does in some
circumstances choose to peel using masks by masking the first iteration of the
loop with an additional alignment mask.
When this is done, the first elements of the predicate can be inactive. In this
example element 1 is inactive based on the calculated misalignment. hence the
-1 value in the first vector IV element.
When we reduce using BIT_FIELD_REF we get the wrong value.
This patch updates it by creating a new scalar PHI that keeps track of whether
we are the first iteration of the loop (with the additional masking) or whether
we have taken a loop iteration already.
The generated sequence:
pre-header:
bb1:
i_1 = <number of leading inactive elements>
Which eliminates the need to do an expensive mask based reduction.
This fixes gromacs with one OpenMP thread. But with > 1 there is still an issue.
gcc/ChangeLog:
PR tree-optimization/119351
* tree-vectorizer.h (LOOP_VINFO_MASK_NITERS_PFA_OFFSET,
LOOP_VINFO_NON_LINEAR_IV): New.
(class _loop_vec_info): Add mask_skip_niters_pfa_offset and
nonlinear_iv.
* tree-vect-loop.cc (_loop_vec_info::_loop_vec_info): Initialize them.
(vect_analyze_scalar_cycles_1): Record non-linear inductions.
(vectorizable_induction): If early break and PFA using masking create a
new phi which tracks where the scalar code needs to start...
(vectorizable_live_operation): ...and generate the adjustments here.
(vect_use_loop_mask_for_alignment_p): Reject non-linear inductions and
early break needing peeling.
gcc/testsuite/ChangeLog:
PR tree-optimization/119351
* gcc.target/aarch64/sve/peel_ind_10.c: New test.
* gcc.target/aarch64/sve/peel_ind_10_run.c: New test.
* gcc.target/aarch64/sve/peel_ind_5.c: New test.
* gcc.target/aarch64/sve/peel_ind_5_run.c: New test.
* gcc.target/aarch64/sve/peel_ind_6.c: New test.
* gcc.target/aarch64/sve/peel_ind_6_run.c: New test.
* gcc.target/aarch64/sve/peel_ind_7.c: New test.
* gcc.target/aarch64/sve/peel_ind_7_run.c: New test.
* gcc.target/aarch64/sve/peel_ind_8.c: New test.
* gcc.target/aarch64/sve/peel_ind_8_run.c: New test.
* gcc.target/aarch64/sve/peel_ind_9.c: New test.
* gcc.target/aarch64/sve/peel_ind_9_run.c: New test.
Tomasz Kamiński [Mon, 14 Apr 2025 14:00:57 +0000 (16:00 +0200)]
libstdc++: Implement formatters for pair and tuple [PR109162]
This patch implements formatter specializations for pair and tuple form
P2286R8. In addition using 'm` and range_format::map (from P2585R1) for
ranges are now supported.
The formatters for pairs and tuples whose corresponding elements are the same
(after applying remove_cvref_t) derive from the same __tuple_formatter class.
This reduce the code duplication, as most of the parsing and formatting is the
same in such cases. We use a custom reduced implementation of the tuple
(__formatters_storage) to store the elements formatters.
Handling of the padding (width and fill) options, is extracted to
__format::__format_padded function, that is used both by __tuple_formatter and
range_formatter. To reduce number of instantations range_formatter::format
triggers, we cast incoming range to __format::__maybe_const_range<_Rg, _CharT>&,
before formatting it.
As in the case of previous commits, the signatures of the user-facing parse
and format methods of the provided formatters deviate from the standard by
constraining types of parameters:
* _CharT is constrained __formatter::__char
* basic_format_parse_context<_CharT> for parse argument
* basic_format_context<_Out, _CharT> for format second argument
The standard specifies last three of above as unconstrained types.
Finally, test for tuple-like std::array and std::ranges::subrange,
that illustrate that they remain formatted as ranges.
PR libstdc++/109162
libstdc++-v3/ChangeLog:
* include/std/format (__formatter_int::_M_format_character_escaped)
(__formatter_str::format): Use __sink.out() to produce _Sink_iter.
(__format::__const_formattable_range): Moved closer to range_formatter.
(__format::__maybe_const_range): Use `__conditional_t` and moved closer
to range_formatter.
(__format::__format_padded, __format::maybe_const)
(__format::__indexed_formatter_storage, __format::__tuple_formatter)
(std::formatter<pair<_Fp, _Sp>, _CharT>>)
(std::formatter<tuple<_Tps...>, _CharT): Define.
(std::formatter<_Rg, _CharT>::format): Cast incoming range to
__format::__maybe_const_range<_Rg, _CharT>&.
(std::formatter<_Rg, _CharT>::_M_format): Extracted from format,
and use __format_padded.
(std::formatter<_Rg, _CharT>::_M_format_no_padding): Rename...
(std::formatter<_Rg, _CharT>::_M_format_elems): ...to this.
(std::formatter<_Rg, _CharT>::_M_format_with_padding): Extracted as
__format_padded.
* testsuite/util/testsuite_iterators.h (test_input_range_nocopy):
Define.
* testsuite/std/format/ranges/formatter.cc: Tests for `m` specifier.
* testsuite/std/format/ranges/sequence.cc: Tests for array and subrange.
* testsuite/std/format/ranges/map.cc: New test.
* testsuite/std/format/tuple.cc: New test.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com> Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
Jakub Jelinek [Wed, 16 Apr 2025 07:11:06 +0000 (09:11 +0200)]
bitintlower: Fix interaction of gimple_assign_copy_p stmts vs. has_single_use [PR119808]
The following testcase is miscompiled, because we emit a CLOBBER in a place
where it shouldn't be emitted.
Before lowering we have:
b_5 = 0;
b.0_6 = b_5;
b.1_1 = (unsigned _BitInt(129)) b.0_6;
...
<retval> = b_5;
The bitint coalescing assigns the same partition/underlying variable
for both b_5 and b.0_6 (possible because there is a copy assignment)
and of course a different one for b.1_1 (and other SSA_NAMEs in between).
This is -O0 so stmts aren't DCEd and aren't propagated that much etc.
It is -O0 so we also don't try to optimize and omit some names from m_names
and handle multiple stmts at once, so the expansion emits essentially
bitint.4 = {};
bitint.4 = bitint.4;
bitint.2 = cast of bitint.4;
bitint.4 = CLOBBER;
...
<retval> = bitint.4;
and the CLOBBER is the problem because bitint.4 is still live afterwards.
We emit the clobbers to improve code generation, but do it only for
(initially) has_single_use SSA_NAMEs (remembered in m_single_use_names)
being used, if they don't have the same partition on the lhs and a few
other conditions.
The problem above is that b.0_6 which is used in the cast has_single_use
and so was in m_single_use_names bitmask and the lhs in that case is
bitint.2, so a different partition. But there is gimple_assign_copy_p
with SSA_NAME rhs1 and the partitioning special cases those and while
b.0_6 is single use, b_5 has multiple uses. I believe this ought to be
a problem solely in the case of such copy stmts and its special case
by the partitioning, if instead of b.0_6 = b_5; there would be
b.0_6 = b_5 + 1; or whatever other stmts that performs or may perform
changes on the value, partitioning couldn't assign the same partition
to b.0_6 and b_5 if b_5 is used later, it couldn't have two different
(or potentially different) values in the same bitint.N var. With
copy that is possible though.
So the following patch fixes it by being more careful when we set
m_single_use_names, don't set it if it is a has_single_use SSA_NAME
but SSA_NAME_DEF_STMT of it is a copy stmt with SSA_NAME rhs1 and that
rhs1 doesn't have single use, or has_single_use but SSA_NAME_DEF_STMT of it
is a copy stmt etc.
Just to make sure it doesn't change code generation too much, I've gathered
statistics how many times
if (m_first
&& m_single_use_names
&& m_vars[p] != m_lhs
&& m_after_stmt
&& bitmap_bit_p (m_single_use_names, SSA_NAME_VERSION (op)))
{
tree clobber = build_clobber (TREE_TYPE (m_vars[p]),
CLOBBER_STORAGE_END);
g = gimple_build_assign (m_vars[p], clobber);
gimple_stmt_iterator gsi = gsi_for_stmt (m_after_stmt);
gsi_insert_after (&gsi, g, GSI_SAME_STMT);
}
emits a clobber on
make check-gcc GCC_TEST_RUN_EXPENSIVE=1 RUNTESTFLAGS="--target_board=unix\{-m64,-m32\} GCC_TEST_RUN_EXPENSIVE=1 dg.exp='*bitint* pr112673.c builtin-stdc-bit-*.c pr112566-2.c pr112511.c pr116588.c pr116003.c pr113693.c pr113602.c flex-array-counted-by-7.c' dg-torture.exp='*bitint* pr116480-2.c pr114312.c pr114121.c' dfp.exp=*bitint* i386.exp='pr118017.c pr117946.c apx-ndd-x32-2a.c' vect.exp='vect-early-break_99-pr113287.c' tree-ssa.exp=pr113735.c"
and before this patch it was 41010 clobbers and after it is 40968,
so difference is 42 clobbers, 0.1% fewer.
2025-04-16 Jakub Jelinek <jakub@redhat.com>
PR middle-end/119808
* gimple-lower-bitint.cc (gimple_lower_bitint): Don't set
m_single_use_names bits for SSA_NAMEs which have single use but
their SSA_NAME_DEF_STMT is a copy from another SSA_NAME which doesn't
have a single use, or single use which is such a copy etc.
Alice Carlotti [Tue, 15 Apr 2025 16:36:25 +0000 (17:36 +0100)]
aarch64: Disable sysreg feature gating
This applies to the sysreg read/write intrinsics __arm_[wr]sr*. It does
not depend on changes to Binutils, because GCC converts recognised
sysreg names to an encoding based form, which is already ungated in Binutils.
We have, however, agreed to make an equivalent change in Binutils (which
would then disable feature gating for sysreg accesses in inline
assembly), but this has not yet been posted upstream.
In the future we may introduce a new flag to renable some checking,
but these checks could not be comprehensive because many system
registers depend on architecture features that don't have corresponding
GCC/GAS --march options. This would also depend on addressing numerous
inconsistencies in the existing list of sysreg feature dependencies.
d: Fix ICE: type variant differs by TYPE_MAX_VALUE with -g [PR119826]
Forward referenced enum types were never fixed up after the main
ENUMERAL_TYPE was finished. All flags set are now propagated to all
variants after its mode, size, and alignment has been calculated.
PR d/119826
gcc/d/ChangeLog:
* types.cc (TypeVisitor::visit (TypeEnum *)): Propagate flags of main
enum types to all forward-referenced variants.
gcc/testsuite/ChangeLog:
* gdc.dg/debug/imports/pr119826b.d: New test.
* gdc.dg/debug/pr119826.d: New test.
c++: Prune lambda captures from more places [PR119755]
Currently, pruned lambda captures are still leftover in the function's
BLOCK and topmost BIND_EXPR; this doesn't cause any issues for normal
compilation, but does break modules streaming as we try to reconstruct a
FIELD_DECL that no longer exists on the type itself.
PR c++/119755
gcc/cp/ChangeLog:
* lambda.cc (prune_lambda_captures): Remove pruned capture from
function's BLOCK_VARS and BIND_EXPR_VARS.
gcc/testsuite/ChangeLog:
* g++.dg/modules/lambda-10_a.H: New test.
* g++.dg/modules/lambda-10_b.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com> Reviewed-by: Jason Merrill <jason@redhat.com>
Jakub Jelinek [Tue, 15 Apr 2025 22:30:09 +0000 (00:30 +0200)]
testsuite: Fix up completion-2.c test
The r15-9487 change has added -flto-partition=default, which broke
the completion-2.c testcase because that case is now also printed
during completion.
2025-04-16 Jakub Jelinek <jakub@redhat.com>
* gcc.dg/completion-2.c: Expect also -flto-partition=default line.
c: Fully fold each parameter for call to .ACCESS_WITH_SIZE [PR119717]
C_MAYBE_CONST_EXPR is a C FE operator that will be removed by c_fully_fold.
In c_fully_fold, it assumes that operands of function calls have already
been folded. However, when we build call to .ACCESS_WITH_SIZE, all its
operands are not fully folded. therefore the C FE specific operator is
passed to middle-end.
In order to fix this issue, fully fold the parameters before building the
call to .ACCESS_WITH_SIZE.
PR c/119717
gcc/c/ChangeLog:
* c-typeck.cc (build_access_with_size_for_counted_by): Fully fold the
parameters for call to .ACCESS_WITH_SIZE.
OpenMP: omp.h omp::allocator C++ Allocator interface
The implementation of each allocator is simplified by inheriting from
__detail::__allocator_templ. At the moment, none of the implementations
diverge in any way, simply passing in the allocator handle to be used when
an allocation is made. In the future, const_mem will need special handling
added to it to support constant memory space.
libgomp/ChangeLog:
* omp.h.in: Add omp::allocator::* and ompx::allocator::* allocators.
(__detail::__allocator_templ<T, omp_allocator_handle_t>):
New struct template.
(null_allocator<T>): New struct template.
(default_mem<T>): Likewise.
(large_cap_mem<T>): Likewise.
(const_mem<T>): Likewise.
(high_bw_mem<T>): Likewise.
(low_lat_mem<T>): Likewise.
(cgroup_mem<T>): Likewise.
(pteam_mem<T>): Likewise.
(thread_mem<T>): Likewise.
(ompx::allocator::gnu_pinned_mem<T>): Likewise.
* testsuite/libgomp.c++/allocator-1.C: New test.
* testsuite/libgomp.c++/allocator-2.C: New test.
Docs: Address -fivopts, -O0, and -Q confusion [PR71094]
There's a blurb at the top of the "Optimize Options" node telling
people that most optimization options are completely disabled at -O0
and a similar blurb in the entry for -Og, but nothing at the entry for
-O0. Since this is a continuing point of confusion it seems wise to
duplicate the information in all the places users are likely to look
for it.
gcc/ChangeLog
PR tree-optimization/71094
* doc/invoke.texi (Optimize Options): Document that -fivopts is
enabled at -O1 and higher. Add blurb about -O0 causing GCC to
completely ignore most optimization options.
projects / thirdparty / gcc.git / log
