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.
Jason Merrill [Tue, 15 Apr 2025 15:23:57 +0000 (11:23 -0400)]
c++: constexpr, trivial, and non-alias target [PR111075]
On Darwin and other targets with !can_alias_cdtor, we instead go to
maybe_thunk_ctor, which builds a thunk function that calls the general
constructor. And then cp_fold tries to constant-evaluate that call, and we
ICE because we don't expect to ever be asked to constant-evaluate a call to
a trivial function.
No new test because this fixes g++.dg/torture/tail-padding1.C on affected
targets.
PR c++/111075
gcc/cp/ChangeLog:
* constexpr.cc (cxx_eval_call_expression): Allow trivial
call from a thunk.
Iain Sandoe [Sun, 29 Dec 2024 23:06:54 +0000 (23:06 +0000)]
includes, Darwin: Handle modular use for macOS SDKs [PR116827].
Recent changes to the OS SDKs have altered the way in which include guards
are used for a number of headers when C++ modules are enabled. Instead of
placing the guards in the included header, they are being placed in the
including header. This breaks the assumptions in the current GCC stddef.h
specifically, that the presence of __PTRDIFF_T and __SIZE_T means that the
relevant defs are already made. However in the case of the module-enabled
C++ with these SDKs, that is no longer true.
stddef.h has a large body of special-cases already, but it seems that the
only viable solution here is to add a new one specifically for __APPLE__
and modular code.
This fixes around 280 new fails in the modules test-suite; it is needed on
all open branches that support modules.
PR target/116827
gcc/ChangeLog:
* ginclude/stddef.h: Undefine __PTRDIFF_T and __SIZE_T for module-
enabled c++ on Darwin/macOS platforms.
Richard Biener [Sat, 15 Mar 2025 14:56:49 +0000 (15:56 +0100)]
cobol/119302 - transform gcobol.3 name during install, install as gcobol-io.3
The following installs gcobol.3 as gcobol-io.3 and applies
program-transform-name to the gcobol-io part. This follows
naming of the pdf and the html variants.
It also uses $(man1ext) and $(man3ext) consistently.
PR cobol/119302
gcc/cobol/
* Make-lang.in (GCOBOLIO_INSTALL_NAME): Define.
Use $(GCOBOLIO_INSTALL_NAME) for gcobol.3 manpage source
upon install.
Jan Hubicka [Tue, 15 Apr 2025 17:09:20 +0000 (19:09 +0200)]
Set znver5 issue rate to 4.
this patch sets issue rate of znver5 to 4. With current model, unless a reservation is
missing, we will never issue more than 4 instructions per cycle since that is the limit
of decoders and the model does not take into acount the fact that typically code is run
from op cache.
gcc/ChangeLog:
* config/i386/x86-tune-sched.cc (ix86_issue_rate): Set
to 4 for znver5.
Jan Hubicka [Tue, 15 Apr 2025 17:04:15 +0000 (19:04 +0200)]
Set ADDSS cost to 3 for znver5
Znver5 has latency of addss 2 in typical case while all earlier versions has latency 3.
Unforunately addss cost is used to cost many other SSE instructions than just addss and
setting the cost to 2 makes us to vectorize 4 64bit stores into one 256bit store which
in turn regesses imagemagick.
This patch sets the cost back to 3. Next stage1 we can untie addss from the other operatoins
and set it correctly.
bootstrapped/regtested x86_64-linux and also benchmarked on SPEC2k17
gcc/ChangeLog:
PR target/119298
* config/i386/x86-tune-costs.h (znver5_cost): Set ADDSS cost to 3.
Jonathan Wakely [Tue, 15 Apr 2025 13:00:23 +0000 (14:00 +0100)]
libstdc++: Do not define __cpp_lib_ranges_iota in <ranges>
In r14-7153-gadbc46942aee75 we removed a duplicate definition of
__glibcxx_want_range_iota from <ranges>, but __cpp_lib_ranges_iota
should be defined in <ranges> at all.
libstdc++-v3/ChangeLog:
* include/std/ranges (__glibcxx_want_ranges_iota): Do not
define.
Jonathan Wakely [Tue, 15 Apr 2025 13:01:55 +0000 (14:01 +0100)]
libstdc++: Do not declare namespace ranges in <numeric> unconditionally
Move namespace ranges inside the feature test macro guard, because
'ranges' is not a reserved name before C++20.
libstdc++-v3/ChangeLog:
* include/std/numeric (ranges): Only declare namespace for C++23
and later.
(ranges::iota_result): Fix indentation.
* testsuite/17_intro/names.cc: Check ranges is not used as an
identifier before C++20.
RISC-V: vsetvl: elide abnormal edges from LCM computations [PR119533]
vsetvl phase4 uses LCM guided info to insert VSETVL insns, including a
straggler loop for "mising vsetvls" on certain edges. Currently it
asserts on encountering EDGE_ABNORMAL.
When enabling go frontend with V enabled, libgo build hits the assert.
The solution is to prevent abnormal edges from getting into LCM at all
(my prior attempt at this just ignored them after LCM which is not
right). Existing invalid_opt_bb_p () current does this for BB predecessors
but not for successors which is what the patch adds.
Crucially, the ICE/fix also depends on avoiding vsetvl hoisting past
non-transparent blocks: That is taken care of by Robin's patch
"RISC-V: Do not lift up vsetvl into non-transparent blocks [PR119547]"
for a different yet related issue.
Reported-by: Heinrich Schuchardt <heinrich.schuchardt@canonical.com> Signed-off-by: Vineet Gupta <vineetg@rivosinc.com>
PR target/119533
Robin Dapp [Fri, 4 Apr 2025 15:06:44 +0000 (17:06 +0200)]
RISC-V: Do not lift up vsetvl into non-transparent blocks [PR119547].
When lifting up a vsetvl into a block we currently don't consider the
block's transparency with respect to the vsetvl as in other parts of the
pass. This patch does not perform the lift when transparency is not
guaranteed.
This condition is more restrictive than necessary as we can still
perform a vsetvl lift if the conflicting register is only every used
in vsetvls and no regular insns but given how late we are in the GCC 15
cycle it seems better to defer this. Therefore
gcc.target/riscv/rvv/vsetvl/avl_single-68.c is XFAILed for now.
This issue was found in OpenCV where it manifests as a runtime error.
Zhijin Zeng debugged PR119547 and provided an initial patch.
projects / thirdparty / gcc.git / log
