aarch64: Check for invalid use arrays in ldp_fusion [PR118320]
As Andrew says in the bugzilla comments, this PR is about a case where
we tried to fuse two stores of x0, one in which x0 was defined and one
in which it was undefined. merge_access_arrays failed on the conflict,
but the failure wasn't caught.
Normally the hazard detection code would fail if the instructions
had incompatible uses. However, an undefined use doesn't impose
many restrictions on movements. I think this is likely to be the
only case where hazard detection isn't enough.
As Andrew notes in bugzilla, it might be possible to allow uses
of defined and undefined values to be merged to the defined value.
But that sounds dangerous in the general case, as an rtl-ssa-level
decision. We might run the risk of turning conditional UB into
unconditional UB. And LLVM proves that the definition of "undef"
isn't simple.
gcc/
PR rtl-optimization/118320
* config/aarch64/aarch64-ldp-fusion.cc (ldp_bb_info::fuse_pair):
Commonize the merge of input_uses and return early if it
fails.
gcc/testsuite/
PR rtl-optimization/118320
* g++.dg/torture/pr118320.C: New test.
Hannes Braun [Thu, 20 Feb 2025 14:09:41 +0000 (15:09 +0100)]
arm: Fix signedness of vld1q intrinsic parms [PR118942]
vld1q_s8_x3, vld1q_s16_x3, vld1q_s8_x4 and vld1q_s16_x4 were expecting
pointers to unsigned integers. These parameters should be pointers to
signed integers.
gcc/ChangeLog:
PR target/118942
* config/arm/arm_neon.h (vld1q_s8_x3): Use int8_t instead of
uint16_t.
(vld1q_s16_x3): Use int16_t instead of uint16_t.
(vld1q_s8_x4): Likewise.
(vld1q_s16_x4): Likewise.
* include/bits/ranges_util.h (__detail::__pair_like_convertible_from):
Use `_Tp` in `is_reference_v` check
* testsuite/std/ranges/subrange/tuple_like.cc: New tests for
pair-like conversion
When a generic lambda calls an overload set containing an iobj member
function we speculatively capture 'this'. We need to do the same
for an xobj member function.
PR c++/119038
gcc/cp/ChangeLog:
* lambda.cc (maybe_generic_this_capture): Consider xobj
member functions as well, not just iobj. Update function
comment.
Fix folding of BIT_NOT_EXPR for POLY_INT_CST [PR118976]
There was an embarrassing typo in the folding of BIT_NOT_EXPR for
POLY_INT_CSTs: it used - rather than ~ on the poly_int. Not sure
how that happened, but it might have been due to the way that
~x is implemented as -1 - x internally.
gcc/
PR tree-optimization/118976
* fold-const.cc (const_unop): Use ~ rather than - for BIT_NOT_EXPR.
* config/aarch64/aarch64.cc (aarch64_test_sve_folding): New function.
(aarch64_run_selftests): Run it.
--cut here--
/* Otherwise, if this register is used by I3, then this register
now dies here, so we must put a REG_DEAD note here unless there
is one already. */
else if (reg_referenced_p (XEXP (note, 0), PATTERN (i3))
&& ! (REG_P (XEXP (note, 0))
? find_regno_note (i3, REG_DEAD,
REGNO (XEXP (note, 0)))
: find_reg_note (i3, REG_DEAD, XEXP (note, 0))))
{
PUT_REG_NOTE_KIND (note, REG_DEAD);
place = i3;
}
--cut here--
Flags register is used in I3, but there already is a REG_DEAD note in I3.
The above condition doesn't trigger and continues in the "else" part where
REG_DEAD note is put to I2. The proposed solution corrects the above
logic to trigger every time the register is referenced in I3, avoiding the
"else" part.
PR rtl-optimization/118739
gcc/ChangeLog:
* combine.cc (distribute_notes) <case REG_UNUSED>: Correct the
logic when the register is used by I3.
Martin Jambor [Tue, 4 Mar 2025 13:53:41 +0000 (14:53 +0100)]
ipa-sra: Avoid clashes with ipa-cp when pulling accesses across calls (PR 118243)
Among other things, IPA-SRA checks whether splitting out a bit of an
aggregate or something passed by reference would lead into a clash
with an already known IPA-CP constant a way which would cause problems
later on. Unfortunately the test is done only in
adjust_parameter_descriptions and is missing when accesses are
propagated from callees to callers, which leads to miscompilation
reported as PR 118243 (where the callee is a function created by
ipa-split).
The matter is then further complicated by the fact that we consider
complex numbers as scalars even though they can be modified piecemeal
(IPA-CP can detect and propagate the pieces separately too) which then
confuses the parameter manipulation machinery furter.
This patch simply adds the missing check to avoid the IPA-SRA
transform in these cases too, which should be suitable for backporting
to all affected release branches. It is a bit of a shame as in the PR
testcase we do propagate both components of the complex number in
question and the transformation phase could recover. I have some
prototype patches in this direction but that is something for (a)
stage 1.
gcc/ChangeLog:
2025-02-10 Martin Jambor <mjambor@suse.cz>
PR ipa/118243
* ipa-sra.cc (pull_accesses_from_callee): New parameters
caller_ipcp_ts and param_idx. Check that scalar pulled accesses would
not clash with a known IPA-CP aggregate constant.
(param_splitting_across_edge): Pass IPA-CP transformation summary and
caller parameter index to pull_accesses_from_callee.
Filip Kastl [Sun, 2 Mar 2025 05:39:17 +0000 (06:39 +0100)]
gimple: sccopy: Prune removed statements from SCCs [PR117919]
While writing the sccopy pass I didn't realize that 'replace_uses_by ()' can
remove portions of the CFG. This happens when replacing arguments of some
statement results in the removal of an EH edge. Because of this sccopy can
then work with GIMPLE statements that aren't part of the IR anymore. In
PR117919 this triggered an assertion within the pass which assumes that
statements the pass works with are reachable.
This patch tells the pass to notice when a statement isn't in the IR anymore
and remove it from it's worklist.
PR tree-optimization/117919
gcc/ChangeLog:
* gimple-ssa-sccopy.cc (scc_copy_prop::propagate): Prune
statements that 'replace_uses_by ()' removed.
Jeff Law [Sun, 29 Dec 2024 15:27:30 +0000 (08:27 -0700)]
[PR target/116720] Fix test for valid mempair operands
So this BZ is a case where we incorrectly indicated that the operand array was
suitable for the t-head load/store pair instructions.
In particular there's a test which checks alignment, but that happens *before*
we know if the operands are going to be reversed. So the routine reported the
operands are suitable.
At a later point the operands have been reversed into the proper order and we
realize the alignment test should have failed, resulting in the unrecognized
insn.
This fixes the code by moving the reversal check earlier and actually swapping
the local variables with the operands. That in turn allows for simpler testing
of alignments, ordering, etc.
I've tested this on rv32 and rv64 in my tester. I don't offhand know if the
patch from Filip that's been causing headaches for the RISC-V port has been
reverted/fixed. So there's a nonzero chance the pre-commit CI tester will
fail. I'll keep an eye on it and act appropriately.
PR target/116720
gcc/
* config/riscv/thead.cc (th_mempair_operands_p): Test for
aligned memory after swapping operands. Simplify test for
first memory access as well.
gcc/testsuite/
* gcc.target/riscv/pr116720.c: New test.
Iain Buclaw [Fri, 28 Feb 2025 18:22:36 +0000 (19:22 +0100)]
d: Fix comparing uninitialized memory in dstruct.d [PR116961]
Floating-point emulation in the D front-end is done via a type named
`struct longdouble`, which in GDC is a small interface around the
real_value type. Because the D code cannot include gcc/real.h directly,
a big enough buffer is used for the data instead.
On x86_64, this buffer is actually bigger than real_value itself, so
when a new longdouble object is created with
there is uninitialized padding at the end of `r`. This was never a
problem when D was implemented in C++ (until GCC 12) as comparing two
longdouble objects with `==' would be forwarded to the relevant
operator== overload that extracted the underlying real_value.
However when the front-end was translated to D, such conditions were
instead rewritten into identity comparisons
return exp.toReal() is CTFloat.zero
The `is` operator gets lowered as a call to `memcmp() == 0', which is
where the read of uninitialized memory occurs, as seen by valgrind.
==26778== Conditional jump or move depends on uninitialised value(s)
==26778== at 0x911F41: dmd.dstruct._isZeroInit(dmd.expression.Expression) (dstruct.d:635)
==26778== by 0x9123BE: StructDeclaration::finalizeSize() (dstruct.d:373)
==26778== by 0x86747C: dmd.aggregate.AggregateDeclaration.determineSize(ref const(dmd.location.Loc)) (aggregate.d:226)
[...]
To avoid accidentally reading uninitialized data, explicitly initialize
all `longdouble` variables with an empty constructor on C++ side of the
implementation before initializing underlying real_value type it holds.
Jonathan Wakely [Wed, 12 Feb 2025 17:29:59 +0000 (17:29 +0000)]
libstdc++: Use init_priority attribute for tzdb globals [PR118811]
When linking statically to libstdc++.a (or to libstdc++_nonshared.a in
the RHEL devtoolset compiler) there's a static initialization order
problem where user code might be constructed before the
std::chrono::tzdb_list globals, and so might try to use them after
they've already been destroyed.
Use the init_priority attribute on those globals so that they are
initialized early. Since r15-7511-g4e7f74225116e7 we can disable the
warnings for using a reserved priority using a diagnostic pragma.
However, for the backport to the release branch the warnings can only be
suppressed by defining the objects in a system header. Move them to a
new file that uses '#pragma GCC system_header' and then include that in
tzdb.cc.
libstdc++-v3/ChangeLog:
PR libstdc++/118811
* src/c++20/tzdb.cc (tzdb_list::_Node): Move definitions of
static data members to new header.
* src/c++20/tzdb_globals.h: New header. Use init_priority
attribute on static data members.
* testsuite/std/time/tzdb_list/pr118811.cc: New test.
Jonathan Wakely [Sat, 1 Jun 2024 09:45:55 +0000 (10:45 +0100)]
libstdc++: Reuse temporary buffer utils in <stacktrace>
The non-throwing allocation logic in std::stacktrace duplicates the
logic in <bits/stl_tempbuf.h>, so we can just reuse those utilities.
libstdc++-v3/ChangeLog:
* include/std/stacktrace (basic_stacktrace::_Impl::_M_allocate):
Use __detail::__get_temporary_buffer.
(basic_stacktrace::_Impl::_M_deallocate): Use
__detail::__return_temporary_buffer.
We get smaller code at all optimization levels by not creating a
temporary object, just comparing lengths first and then using
traits_type::compare. This does less work than calling substr then
operator==.
libstdc++-v3/ChangeLog:
* include/std/string_view (starts_with(basic_string_view)):
Compare lengths first and then call traits_type::compare
directly.
Jonathan Wakely [Wed, 26 Jun 2024 13:09:07 +0000 (14:09 +0100)]
libstdc++: Do not use C++11 alignof in C++98 mode [PR104395]
When -faligned-new (or Clang's -faligned-allocation) is used our
allocators try to support extended alignments, gated on the
__cpp_aligned_new macro. However, because they use alignof(_Tp) which is
not a keyword in C++98 mode, using -std=c++98 -faligned-new results in
errors from <memory> and other headers.
We could change them to use __alignof__ instead of alignof, but that
would potentially alter the result of the conditions, because e.g.
alignof(long long) != __alignof__(long long) on some targets. That's
probably not an issue for any types with extended alignment, so maybe it
would be a safe change.
For now, it seems acceptable to just disable the extended alignment
support in C++98 mode, so that -faligned-new enables std::align_val_t
and the corresponding operator new overloads, but doesn't affect
std::allocator, __gnu_cxx::__bitmap_allocator etc.
libstdc++-v3/ChangeLog:
PR libstdc++/104395
* include/bits/new_allocator.h: Disable extended alignment
support in C++98 mode.
* include/bits/stl_tempbuf.h: Likewise.
* include/ext/bitmap_allocator.h: Likewise.
* include/ext/malloc_allocator.h: Likewise.
* include/ext/mt_allocator.h: Likewise.
* include/ext/pool_allocator.h: Likewise.
* testsuite/ext/104395.cc: New test.
Jonathan Wakely [Tue, 18 Jun 2024 19:53:53 +0000 (20:53 +0100)]
libstdc++: Fix warning regressions in <bits/stl_tempbuf.h>
I caused some new warnings with -Wsystem-headers with my recent changes
to std::get_temporary_buffer and std::_Temporary_buffer. There's a
-Wsign-compare warning which can be avoided by casting the ptrdiff_t
argument to size_t (which also conveniently rejects negative values).
There's also a -Wdeprecated-declarations warning because I moved where
std::get_temporary_buffer is called, but didn't move the diagnostic
pragmas that suppress the warning for calling it.
libstdc++-v3/ChangeLog:
* include/bits/stl_tempbuf.h (__get_temporary_buffer): Cast
argument to size_t to handle negative values and suppress
-Wsign-compare warning.
(_Temporary_buffer): Move diagnostic pragmas to new location of
call to std::get_temporary_buffer.
Jonathan Wakely [Wed, 13 Apr 2022 12:03:44 +0000 (13:03 +0100)]
libstdc++: Handle extended alignment in std::get_temporary_buffer [PR105258]
This adds extended alignment support to std::get_temporary_buffer etc.
so that when std::stable_sort uses a temporary buffer it works for
overaligned types.
Also simplify the _Temporary_buffer type by using RAII for the
allocation, via a new data member. This simplifies the _Temporary_buffer
constructor and destructor by makingthem only responsible for
constructing and destroying the elements, not managing the memory.
libstdc++-v3/ChangeLog:
PR libstdc++/105258
* include/bits/stl_tempbuf.h (__detail::__get_temporary_buffer):
New function to do allocation for get_temporary_buffer, with
extended alignment support.
(__detail::__return_temporary_buffer): Support extended
alignment.
(get_temporary_buffer): Use __get_temporary_buffer.
(return_temporary_buffer): Support extended alignment. Add
deprecated attribute.
(_Temporary_buffer): Move allocation and deallocation into a
subobject and remove try-catch block in constructor.
(__uninitialized_construct_buf): Use argument deduction for
value type.
* testsuite/20_util/temporary_buffer.cc: Add dg-warning for new
deprecated warning.
* testsuite/25_algorithms/stable_sort/overaligned.cc: New test.
libstdc++: fix a dangling reference crash in ranges::is_permutation [PR118160]
The code was caching the result of `invoke(proj, *it)` in a local
`auto &&` variable. The problem is that this may create dangling
references, for instance in case `proj` is `std::identity` (the common
case) and `*it` produces a prvalue: lifetime extension does not
apply here due to the expressions involved.
Instead, store (and lifetime-extend) the result of `*it` in a separate
variable, then project that variable. While at it, also forward the
result of the projection to the predicate, so that the predicate can
act on the proper value category.
libstdc++-v3/ChangeLog:
PR libstdc++/118160
PR libstdc++/100249
* include/bits/ranges_algo.h (__is_permutation_fn): Avoid a
dangling reference by storing the result of the iterator
dereference and the result of the projection in two distinct
variables, in order to lifetime-extend each one.
Forward the projected value to the predicate.
* testsuite/25_algorithms/is_permutation/constrained.cc: Add a
test with a range returning prvalues. Test it in a constexpr
context, in order to rely on the compiler to catch UB.
Jonathan Wakely [Thu, 5 Dec 2024 12:46:26 +0000 (12:46 +0000)]
libstdc++: Use ADL swap for containers' function objects [PR117921]
The standard says that Compare, Pred and Hash objects should be swapped
as described in [swappable.requirements] which means calling swap
unqualified with std::swap visible to name lookup.
libstdc++-v3/ChangeLog:
PR libstdc++/117921
* include/bits/hashtable_policy.h (_Hash_code_base::_M_swap):
Use ADL swap for Hash members.
(_Hashtable_base::_M_swap): Use ADL swap for _Equal members.
* include/bits/stl_tree.h (_Rb_tree::swap): Use ADL swap for
_Compare members.
* testsuite/23_containers/set/modifiers/swap/adl.cc: New test.
* testsuite/23_containers/unordered_set/modifiers/swap-2.cc: New
test.
Jonathan Wakely [Fri, 15 Nov 2024 22:03:20 +0000 (22:03 +0000)]
libstdc++: Add debug assertions to std::list and std::forward_list
While working on fancy pointer support for the linked lists I noticed
they didn't have any debug assertions. This adds the obvious non-empty
assertions to front() and back().
Jonathan Wakely [Mon, 30 Dec 2024 13:08:41 +0000 (13:08 +0000)]
libstdc++: Implement LWG 2937 for std::filesystem::equivalent [PR118158]
Do not report an error for (is_other(s1) && is_other(s2)) as the
standard originally said, nor for (is_other(s1) || is_other(s2)) as
libstdc++ was doing. We can compare inode numbers for special files and
so give sensible answers.
libstdc++-v3/ChangeLog:
PR libstdc++/118158
* src/c++17/fs_ops.cc (fs::equivalent): Remove error reporting
for is_other(s1) && is_other(s2) case, as per LWG 2937.
* testsuite/27_io/filesystem/operations/pr118158.cc: New test.
Jason Merrill [Sat, 15 Feb 2025 23:17:30 +0000 (00:17 +0100)]
testsuite: limit concepts-pr67774.C to C++20
This test breaks with -std=c++23 -fconcepts-ts, but works at the default
-std=c++20 -fconcepts-ts. Since we're removing -fconcepts-ts in GCC 15,
it's not worth trying to fix this conflict.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-pr67774.C: Change target to c++20_only.
Jason Merrill [Sat, 15 Feb 2025 09:48:17 +0000 (10:48 +0100)]
c++: NRVO, constexpr, lambda [PR118053]
Here during constant evaluation we encounter a VAR_DECL with DECL_VALUE_EXPR
of the RESULT_DECL, where the latter has been adjusted for
pass-by-invisible-reference. We already had the code to deal with this, we
just need to use it in the non-capture case of DECL_VALUE_EXPR as well.
PR c++/118053
gcc/cp/ChangeLog:
* constexpr.cc (cxx_eval_constant_expression): Generalize
DECL_VALUE_EXPR invisiref handling.
Jason Merrill [Tue, 28 Jan 2025 22:39:41 +0000 (17:39 -0500)]
c++: disable initializer_list transformation
PRs 118673 and 118285 are wrong-code bugs with the transformation to build
an initializer_list backing array from a static array of the initializer
expressions; let's disable that transformation on the GCC 14 branch.
PR c++/118673
PR c++/118285
gcc/cp/ChangeLog:
* call.cc (convert_like_internal) [ck_list]: Stop using
maybe_init_list_as_array for GCC 14.
Jason Merrill [Mon, 27 Jan 2025 23:30:18 +0000 (18:30 -0500)]
c++: init-list opt and lvalue initializers [PR118673]
When fn returns {extension}, the ArrayRef in the initializer_list is
constructed to point to 'extension', the variable with static storage
duration. The optimization was copying extension's value into a temporary
array and constructing the ArrayRef to point to that temporary copy instead,
resulting in a dangling pointer. So suppress this optimization if the
element constructor takes a reference and the initializer is a non-mergeable
lvalue.
Jason Merrill [Tue, 28 Jan 2025 18:11:50 +0000 (13:11 -0500)]
c++: constexpr VEC_INIT_EXPR [PR118285]
cxx_eval_vec_init_1 was doing the wrong thing for an array of
self-referential class type; just evaluating the TARGET_EXPR initializer
creates a new object that refers to the TARGET_EXPR_SLOT, if we want it to
refer properly to the initialization target we need to provide it.
PR c++/118285
gcc/cp/ChangeLog:
* constexpr.cc (cxx_eval_vec_init_1): Build INIT_EXPR for
initializing a class.
where the shift count operand does not trivially fit the scheme of
address operands. Reject those operands, especially since
strip_address_mutations() expects expressions of the form
(and ... (const_int ...)) and fails for (and ... (const_wide_int ...)).
Thus, be more strict here and accept only CONST_INT operands. Done by
replacing immediate_operand() with const_int_operand() which is enough
since the former only additionally checks for LEGITIMATE_PIC_OPERAND_P
and targetm.legitimate_constant_p which are always true for CONST_INT
operands.
While on it, fix indentation of the if block.
gcc/ChangeLog:
PR target/118835
* config/s390/s390.cc (s390_valid_shift_count): Reject shift
count operands which do not trivially fit the scheme of
address operands.
Richard Biener [Fri, 7 Feb 2025 13:42:23 +0000 (14:42 +0100)]
jit/118780 - make sure to include dlfcn.h when plugin support is disabled
The following makes the dlfcn.h explicitly requested which avoids
build failure when JIT is enabled but plugin support disabled as
currently the include is conditional on plugin support.
PR jit/118780
gcc/
* system.h: Check INCLUDE_DLFCN_H for including dlfcn.h instead
of ENABLE_PLUGIN.
* plugin.cc: Define INCLUDE_DLFCN_H.
Richard Biener [Mon, 3 Feb 2025 08:55:50 +0000 (09:55 +0100)]
tree-optimization/118717 - store commoning vs. abnormals
When we sink common stores in cselim or the sink pass we have to
make sure to not introduce overlapping lifetimes for abnormals
used in the ref. The easiest is to avoid sinking stmts which
reference abnormals at all which is what the following does.
PR tree-optimization/118717
* tree-ssa-phiopt.cc (cond_if_else_store_replacement_1):
Do not common stores referencing abnormal SSA names.
* tree-ssa-sink.cc (sink_common_stores_to_bb): Likewise.
Richard Biener [Wed, 8 Jan 2025 08:25:52 +0000 (09:25 +0100)]
tree-optimization/117979 - failed irreducible loop update from DCE
When CD-DCE creates forwarders to reduce false control dependences
it fails to update the irreducible state of edge and the forwarder
block in case the fowarder groups both normal (entry) and edges
from an irreducible region (necessarily backedges). This is because
when we split the first edge, if that's a normal edge, the forwarder
and its edge to the original block will not be marked as part
of the irreducible region but when we then redirect an edge from
within the region it becomes so.
The following fixes this up.
Note I think creating a forwarder that includes backedges is
likely not going to help, but at this stage I don't want to change
the CFG going into DCE. For regular loops we'll have a single
entry and a single backedge by means of loop init and will never
create a forwarder - so this is solely happening for irreducible
regions where it's harder to prove that such forwarder doesn't help.
PR tree-optimization/117979
* tree-ssa-dce.cc (make_forwarders_with_degenerate_phis):
Properly update the irreducible region state.
Richard Biener [Mon, 3 Feb 2025 14:12:52 +0000 (15:12 +0100)]
tree-optimization/117113 - ICE with unroll-and-jam
When there's an inner loop without virtual header PHI but the outer
loop has one the fusion process cannot handle the need to create
an inner loop virtual header PHI. Punt in this case.
PR tree-optimization/117113
* gimple-loop-jam.cc (unroll_jam_possible_p): Detect when
we cannot handle virtual SSA update.
Richard Biener [Mon, 3 Feb 2025 13:27:01 +0000 (14:27 +0100)]
lto/113207 - fix free_lang_data_in_type
When we process function types we strip volatile and const qualifiers
after building a simplified type variant (which preserves those).
The qualified type handling of both isn't really compatible, so avoid
bad interaction by swapping this, first dropping const/volatile
qualifiers and then building the simplified type thereof.
PR lto/113207
* ipa-free-lang-data.cc (free_lang_data_in_type): First drop
const/volatile qualifiers from function argument types,
then build a simplified type.
but since r106 is used we wrongly materialize it using a subreg:
modifying insn i3 10: r106:V4QI=r109:V4SI#0
which of course does not work for modes with more than one component,
specifically vector and complex modes.
PR rtl-optimization/118662
* combine.cc (try_combine): When re-materializing a load
from an extended reg by a lowpart subreg make sure we're
not dealing with vector or complex modes.
Richard Biener [Tue, 28 Jan 2025 11:28:14 +0000 (12:28 +0100)]
tree-optimization/117424 - invalid LIM of trapping ref
The following addresses a bug in tree_could_trap_p leading to
hoisting of a possibly trapping, because of out-of-bound, access.
We only ensured the first accessed byte is within a decl there,
the patch makes sure the whole base of the reference is within it.
This is pessimistic if a handled component would then subset to
a sub-object within the decl but upcasting of a decl to larger
types should be uncommon, questionable, and wrong without
-fno-strict-aliasing.
The testcase is a bit fragile, but I could not devise a (portable)
way to ensure an out-of-bound access to a decl would fault.
PR tree-optimization/117424
* tree-eh.cc (tree_could_trap_p): Verify the base is
fully contained within a decl.
Richard Biener [Tue, 1 Oct 2024 08:37:16 +0000 (10:37 +0200)]
tree-optimization/116906 - unsafe PRE with never executed edges
When we're computing ANTIC for PRE we treat edges to not yet visited
blocks as having a maximum ANTIC solution to get at an optimistic
solution in the iteration. That assumes the edges visted eventually
execute. This is a wrong assumption that can lead to wrong code
(and not only non-optimality) when possibly trapping expressions
are involved as the testcases in the PR show. The following mitigates
this by pruning trapping expressions from ANTIC computed when
maximum sets are involved.
PR tree-optimization/116906
* tree-ssa-pre.cc (prune_clobbered_mems): Add clean_traps
argument.
(compute_antic_aux): Direct prune_clobbered_mems to prune
all traps when any MAX solution was involved in the ANTIC
computation.
(compute_partial_antic_aux): Adjust.
* gcc.dg/pr116906-1.c: New testcase.
* gcc.dg/pr116906-2.c: Likewise.
Richard Biener [Wed, 15 Jan 2025 13:31:57 +0000 (14:31 +0100)]
tree-optimization/115494 - PRE PHI translation and ranges
When we PHI translate dependent expressions we keep SSA defs in
place of the translated expression in case the expression itself
did not change even though it's context did and thus the validity
of ranges associated with it. That eventually leads to simplification
errors given we violate the precondition that used SSA defs fed to
vn_valueize are valid to use (including their associated ranges).
The following makes sure to replace those with new representatives
always, not only when the dependent expression translation changed it.
The fix was originally discovered by Michael Morin.
PR tree-optimization/115494
* tree-ssa-pre.cc (phi_translate_1): Always generate a
representative for translated dependent expressions.
Richard Biener [Wed, 29 Jan 2025 12:25:14 +0000 (13:25 +0100)]
tree-optimization/114052 - consider infinite sub-loops when lowering iter bound
When we walk stmts to find always executed stmts with UB in the last
iteration to be able to reduce the iteration count by one we fail
to consider infinite subloops in the last iteration that would make
such stmt not execute. The following adds this.
PR tree-optimization/114052
* tree-ssa-loop-niter.cc (maybe_lower_iteration_bound): Check
for infinite subloops we might not exit.
Richard Biener [Thu, 23 Jan 2025 12:10:17 +0000 (13:10 +0100)]
tree-optimization/112859 - bogus loop distribution
When we get a zero distance vector we still have to check for the
situation of a common inner loop with zero distance. But we can
still allow a zero distance for the loop we distribute
(gcc.dg/tree-ssa/ldist-33.c is such a case). This is because
zero distances in non-outermost loops are a misrepresentation
of dependence by dependence analysis.
Note that test coverage of loop distribution of loop nests is
very low.
PR tree-optimization/112859
PR tree-optimization/115347
* tree-loop-distribution.cc
(loop_distribution::pg_add_dependence_edges): For a zero
distance vector still make sure to not have an inner
loop with zero distance.
* gcc.dg/torture/pr112859.c: New testcase.
* gcc.dg/torture/pr115347.c: Likewise.
Harald Anlauf [Sat, 15 Feb 2025 19:36:15 +0000 (20:36 +0100)]
Fortran: passing of derived type to VALUE,OPTIONAL dummy argument [PR118080]
For scalar OPTIONAL dummy arguments with the VALUE attribute, gfortran
passes a hidden flag to denote presence or absence of the actual argument
for intrinsic types. Extend this treatment to derived type (user-defined
as well as from intrinsic module ISO_C_BINDING).
PR fortran/118080
gcc/fortran/ChangeLog:
* gfortran.texi: Adjust documentation.
* trans-decl.cc (create_function_arglist): Adjust to pass hidden
presence flag also for derived type dummies with VALUE,OPTIONAL
attribute.
* trans-expr.cc (gfc_conv_expr_present): Expect hidden presence
flag also for derived type dummies with VALUE,OPTIONAL attribute.
(conv_cond_temp): Adjust to allow derived types.
(conv_dummy_value): Extend to handle derived type dummies with
VALUE,OPTIONAL attribute.
(gfc_conv_procedure_call): Adjust for actual arguments passed to
derived type dummies with VALUE,OPTIONAL attribute.
* trans-types.cc (gfc_get_function_type): Adjust fndecl for
hidden presence flag.
Lulu Cheng [Wed, 12 Feb 2025 06:29:58 +0000 (14:29 +0800)]
LoongArch: Fix the issue of function jump out of range caused by crtbeginS.o [PR118844].
Due to the presence of R_LARCH_B26 in
/usr/lib/gcc/loongarch64-linux-gnu/14/crtbeginS.o, its addressing
range is [PC-128MiB, PC+128MiB-4]. This means that when the code
segment size exceeds 128MB, linking with lld will definitely fail
(ld will not fail because the order of the two is different).
Andreas Tobler [Sun, 9 Jun 2024 21:18:04 +0000 (23:18 +0200)]
FreeBSD: Stop linking _p libs for -pg as of FreeBSD 14
As of FreeBSD version 14, FreeBSD no longer provides profiled system
libraries like libc_p and libpthread_p. Stop linking against them if
the FreeBSD major version is 14 or more.
gcc:
* config/freebsd-spec.h: Change fbsd-lib-spec for FreeBSD > 13,
do not link against profiled system libraries if -pg is invoked.
Add a define to note about this change.
* config/aarch64/aarch64-freebsd.h: Use the note to inform if
-pg is invoked on FreeBSD > 13.
* config/arm/freebsd.h: Likewise.
* config/i386/freebsd.h: Likewise.
* config/i386/freebsd64.h: Likewise.
* config/riscv/freebsd.h: Likewise.
* config/rs6000/freebsd64.h: Likewise.
* config/rs6000/sysv4.h: Likeise.
Haochen Jiang [Tue, 11 Feb 2025 03:29:34 +0000 (11:29 +0800)]
i386: Deprecate -m[no-]avx10.1 and make -mno-avx10.1-512 to disable the whole AVX10.1
Based on the feedback we got, we would like to re-alias avx10.x to 512
bit in the future. This leaves the current avx10.1 alias to 256 bit
inconsistent. Since it has been there for GCC 14.1 and GCC 14.2,
we decide to deprecate avx10.1 alias. The current proposal is not
adding it back in the future, but it might change if necessary.
For -mno- options, it is confusing what it is disabling when it comes
to avx10. Since there is barely usage enabling AVX10 with 512 bit
then disabling it, we will only provide -mno-avx10.x options in the
future, disabling the whole AVX10.x. If someone really wants to disable
512 bit after enabling it, -mavx10.x-512 -mno-avx10.x -mavx10.x-256 is
the only way to do that since we also do not want to break the usual
expression on -m- options enabling everything mentioned.
However, for avx10.1, since we deprecated avx10.1, there is no reason
we should have -mno-avx10.1. Thus, we need to keep -mno-avx10.1-[256,512].
To avoid confusion, we will make -mno-avx10.1-512 to disable the
whole AVX10.1 set to match the future -mno-avx10.x.
Haochen Jiang [Mon, 10 Feb 2025 08:53:27 +0000 (16:53 +0800)]
i386: Do not check vector size conflict when AVX512 is not explicitly set [PR 118815]
When AVX512 is not explicitly set, we should not take EVEX512 bit into
consideration when checking vector size. It will solve the intrin header
file reporting warnings when compiling with -Wsystem-headers.
However, there is side effect on the usage for '-march=xxx -mavx10.1-256',
where xxx is with AVX512. It will not report warning on vector size for now.
Since it is a rare usage, we will take it.
gcc/ChangeLog:
PR target/118815
* config/i386/i386-options.cc (ix86_option_override_internal):
Do not check vector size conflict when AVX512 is not explicitly
set.
Gaius Mulley [Fri, 14 Feb 2025 19:17:02 +0000 (19:17 +0000)]
[PATCH] PR modula2/118761: gm2 driver doesnt behave as gcc for -fhelp=BLA
This patch enables the gm2 driver to handle -fsyntax-only -fhelp=optimizers,
for example, correctly without terminating with gm2: fatal error:
no input files.
gcc/m2/ChangeLog:
PR modula2/118761
* gm2spec.cc (lang_specific_driver): Add case clauses for
OPT__help, OPT__help_ set in_added_libraries to 0 and early
return.
Marek Polacek [Tue, 26 Nov 2024 19:37:21 +0000 (14:37 -0500)]
driver: -fhardened and -z lazy/-z norelro [PR117739]
As the manual states, using "-fhardened -fstack-protector" will produce
a warning because -fhardened wants to enable -fstack-protector-strong,
but it can't since it's been overriden by the weaker -fstack-protector.
-fhardened also attempts to enable -Wl,-z,relro,-z,now. By the same
logic as above, "-fhardened -z norelro" or "-fhardened -z lazy" should
produce the same warning. But we don't detect this combination, so
this patch fixes it. I also renamed a variable to better reflect its
purpose.
Also don't check warn_hardened in process_command, since it's always
true there.
Also tweak wording in the manual as Jon Wakely suggested on IRC.
PR driver/117739
gcc/ChangeLog:
* doc/invoke.texi: Tweak wording for -Whardened.
* gcc.cc (driver_handle_option): If -z lazy or -z norelro was
specified, don't enable linker hardening.
(process_command): Don't check warn_hardened.
gcc/testsuite/ChangeLog:
* c-c++-common/fhardened-16.c: New test.
* c-c++-common/fhardened-17.c: New test.
* c-c++-common/fhardened-18.c: New test.
* c-c++-common/fhardened-19.c: New test.
* c-c++-common/fhardened-20.c: New test.
* c-c++-common/fhardened-21.c: New test.
Gaius Mulley [Thu, 13 Feb 2025 18:17:17 +0000 (18:17 +0000)]
[PATCH] PR modula2/115112 Incorrect line debugging information occurs during INC builtin
This patch fixes location bugs in BuildDecProcedure,
BuildIncProcedure, BuildInclProcedure, BuildExclProcedure and
BuildThrow. All these procedure functions use the token position
passed as a parameter (rather than from the quad stack). It also
fixes location bugs in CheckRangeIncDec to ensure that the token
position is stored on the quad stack before calling subsidiary
procedure functions.
gcc/m2/ChangeLog:
PR modula2/115112
* gm2-compiler/M2Quads.mod (BuildPseudoProcedureCall): Pass
tokno to each build procedure.
(BuildThrowProcedure): New parameter functok.
(BuildIncProcedure): New parameter proctok.
Pass proctok on the quad stack during every push.
(BuildDecProcedure): Ditto.
(BuildInclProcedure): New parameter proctok.
(BuildExclProcedure): New parameter proctok.
gcc/testsuite/ChangeLog:
PR modula2/115112
* gm2/pim/run/pass/dectest.mod: New test.
* gm2/pim/run/pass/inctest.mod: New test.
Nathaniel Shead [Wed, 12 Feb 2025 12:07:43 +0000 (23:07 +1100)]
c++: Constrain visibility for CNTTPs with internal types [PR118849]
While looking into PR118846 I noticed that we don't currently constrain
the linkage of functions involving CNTTPs of internal-linkage types. It
seems to me that this would be sensible to do.
PR c++/118849
gcc/cp/ChangeLog:
* decl2.cc (min_vis_expr_r): Constrain visibility according to
the type of decl_constant_var_p decls.
This patch builds access to the gcc builtins clz, clzl, clzll,
ctz, ctzl and ctzll within m2builtins.cc. The patch provides
modula2 api access to clz, clzll, ctz and ctzll though the
Builtins definition module. This PR was raised because of
PR118689.
Haochen Jiang [Mon, 10 Feb 2025 06:00:57 +0000 (14:00 +0800)]
i386: Fix AVX512BW intrin header with __OPTIMIZE__ [PR 118813]
When moving intrins around for AVX10 implementation in GCC 14,
the intrin _kshiftli_mask32 and _kshiftri_mask32 are wrongly
wrapped by "#if __OPTIMIZE__" instead of "#ifdef __OPTIMIZE__",
leading to the intrin file not `-Wsystem-headers -Wundef` clean
since r14-4490.
Jakub Jelinek [Sat, 8 Feb 2025 07:54:31 +0000 (08:54 +0100)]
i386: Fix ICE with conditional QI/HI vector maxmin [PR118776]
The following testcase ICEs starting with GCC 12 since r12-4526
although the bug has been introduced already in r12-2751.
The problem was in the addition of cond_<code><mode> define_expand
which uses nonimmediate_operand predicates for both maxmin operands
for all VI1248_AVX512VLBW modes. It works fine with
VI48_AVX512VL modes because the <code><mode>3_mask VI48_AVX512VL
define_expand uses ix86_fixup_binary_operands_no_copy and the
*avx512f_<code><mode>3<mask_name> VI48_AVX512VL define_insn uses
% in constraint and !(MEM_P && MEM_P) check in condition (and
<code><mode>3 define_expand with VI124_256_AVX512F_AVX512BW iterator
does that too), but eventhough the 8-bit and 16-bit element maxmin
is commutative too, the <mask_codefor><code><mode>3<mask_name>
define_insn with VI12_AVX512VL iterator didn't use % in constraint
to make it commutative. So, e.g. cond_umaxv32qi define_expand
allowed nonimmediate_operand for both umax operands, but used
gen_umaxv32qi_mask which wasn't commutative and only allowed
nonimmediate_operand for the second operand.
The following patch fixes it by keeping the <code><mode>3
VI124_256_AVX512F_AVX512BW define_expand as is (it does
ix86_fixup_binary_operands_no_copy) but extending the
<code><mode>3_mask define_expand from VI48_AVX512VL to
VI1248_AVX512VLBW which keeps the current modes with their
ISA conditions and adds the VI12_AVX512VL modes under additional
TARGET_AVX512BW condition, and turning the actual define_insn
into an * prefixed name (which it was before just for the non-masked
case) and having the same commutative operand handling as in other
define_insns.
2025-02-08 Jakub Jelinek <jakub@redhat.com>
PR target/118776
* config/i386/sse.md (<code><mode>3_mask): Use VI1248_AVX512VLBW
iterator rather than VI48_AVX512VL.
(<mask_codefor><code><mode>3<mask_name>): Rename to ...
(*avx512bw_<code><mode>3<mask_name>): ... this. Use
nonimmediate_operand rather than register_operand predicate and %v
rather than v constraint for operand 1 and adjust condition to reject
MEMs in both operand 1 and 2.
Jakub Jelinek [Fri, 7 Feb 2025 16:08:39 +0000 (17:08 +0100)]
c++: Fix up name independent decl in structured binding handling in range for [PR115586]
cp_parser_range_for temporarily reverts IDENTIFIER_BINDING changes
to hide the decls from the structured bindings from lookup during
parsing of the expression after :
If there are 2 or more name independent decls, we undo IDENTIFIER_BINDING
for the same name multiple times, even when just one has been added
(with a TREE_LIST inside of it as decl).
The following patch fixes it by handling the _ name at most once, the
later loop will DTRT then and just reinstall the temporarily hidden
binding with the TREE_LIST in there.
2025-02-07 Jakub Jelinek <jakub@redhat.com>
PR c++/115586
* parser.cc (cp_parser_range_for): For name independent decls in
structured bindings, only push the name/binding once per
structured binding.
* g++.dg/cpp26/name-independent-decl9.C: New test.
* g++.dg/cpp26/name-independent-decl10.C: New test.
Jakub Jelinek [Fri, 7 Feb 2025 13:30:11 +0000 (14:30 +0100)]
c++: Don't use CLEANUP_EH_ONLY for new expression cleanup [PR118763]
The following testcase is miscompiled since r12-6325 stopped
preevaluating the initializers for new expression.
If evaluating the initializers throws, there is a correct cleanup
for that, but it is marked CLEANUP_EH_ONLY. While in standard
C++ that is just fine, if it has statement expressions, it can
return or goto out of the expression and we should delete the
pointer in that case too.
There is already a sentry variable initialized to true and
set to false after everything is initialized and used as a guard
for the cleanup, so just removing the CLEANUP_EH_ONLY flag does
everything we need. And in the normal case of the initializer
not using statement expressions at least with -O2 we get the same code,
while the change changes one
try { sentry = true; ... sentry = false; } catch { if (sentry) delete ...; }
into
try { sentry = true; ... sentry = false; } finally { if (sentry) delete ...; }
optimizations will see that sentry is false when reaching the finally
other than through an exception.
Though, wonder what other CLEANUP_EH_ONLY cleanups might be an issue
with statement expressions.
2025-02-07 Jakub Jelinek <jakub@redhat.com>
PR c++/118763
* init.cc (build_new_1): Don't set CLEANUP_EH_ONLY.
Jakub Jelinek [Fri, 7 Feb 2025 13:27:18 +0000 (14:27 +0100)]
c++: Allow constexpr reads from volatile std::nullptr_t objects [PR118661]
As mentioned in the PR, https://eel.is/c++draft/conv.lval#note-1
says that even volatile reads from std::nullptr_t typed objects actually
don't read anything and https://eel.is/c++draft/expr.const#10.9
says that even those are ok in constant expressions.
So, the following patch adjusts the r9-4793 changes to have an exception
for NULLPTR_TYPE.
As [conv.lval]/3 also talks about accessing to inactive member, I've added
testcase to cover that as well.
2025-02-07 Jakub Jelinek <jakub@redhat.com>
PR c++/118661
* constexpr.cc (potential_constant_expression_1): Don't diagnose
lvalue-to-rvalue conversion of volatile lvalue if it has NULLPTR_TYPE.
* decl2.cc (decl_maybe_constant_var_p): Return true for constexpr
decls with NULLPTR_TYPE even if they are volatile.
* g++.dg/cpp0x/constexpr-volatile4.C: New test.
* g++.dg/cpp0x/constexpr-union9.C: New test.
Jakub Jelinek [Thu, 6 Feb 2025 14:39:18 +0000 (15:39 +0100)]
loop-iv, riscv: Fix get_biv_step_1 for RISC-V [PR117506]
The following test ICEs on RISC-V at least latently since r14-1622-g99bfdb072e67fa3fe294d86b4b2a9f686f8d9705 which added
RISC-V specific case to get_biv_step_1 to recognize also
({zero,sign}_extend:DI (plus:SI op0 op1))
The reason for the ICE is that op1 in this case is CONST_POLY_INT
which unlike the really expected VOIDmode CONST_INTs has its own
mode and still satisfies CONSTANT_P.
GET_MODE (rhs) (SImode) is different from outer_mode (DImode), so
the function later does
*inner_step = simplify_gen_binary (code, outer_mode,
*inner_step, op1);
but that obviously ICEs because while *inner_step is either VOIDmode
or DImode, op1 has SImode.
The following patch fixes it by extending op1 using code so that
simplify_gen_binary can handle it. Another option would be
to change the !CONSTANT_P (op1) 3 lines above this to
!CONST_INT_P (op1), I think it isn't very likely that we get something
useful from other constants there.
2025-02-06 Jakub Jelinek <jakub@redhat.com>
PR rtl-optimization/117506
* loop-iv.cc (get_biv_step_1): For {ZERO,SIGN}_EXTEND
of PLUS apply {ZERO,SIGN}_EXTEND to op1.
* gcc.dg/pr117506.c: New test.
* gcc.target/riscv/pr117506.c: New test.
Jakub Jelinek [Fri, 31 Jan 2025 23:50:24 +0000 (00:50 +0100)]
icf: Compare call argument types in certain cases and asm operands [PR117432]
compare_operand uses operand_equal_p under the hood, which e.g. for
INTEGER_CSTs will just match the values rather regardless of their types.
Now, in many comparing the type is redundant, if we have
x_2 = y_3 + 1;
we've already compared the type for the lhs and also for rhs1, there won't
be any surprises on rhs2.
As noted in the PR, there are cases where the type of the operand is the
sole place of information and we don't want to ICF merge functions if the
types differ.
One case is stdarg functions, arguments passed to ..., it is different
if we pass 1, 1L, 1LL.
Another case are the K&R unprototyped functions (sure, gone in C23).
And yet another case are inline asm operands, "r" (1) is different from "r"
(1L) from "r" (1LL).
So, the following patch determines based on lack of fntype (e.g. for
internal functions), or on !prototype_p, or on stdarg_p (in that case
using number of named arguments) which arguments need to have type checked
and does that, plus compares types on inline asm operands (maybe it would be
enough to do that just for input operands but we have just a routine to
handle both and I didn't feel we need to differentiate).
Furthermore, I've noticed fntype{1,2} isn't actually compared if it is a
direct call (gimple_call_fndecl is non-NULL). That is wrong too, we could
have
void (*fn) (int, long long) = (void (*) (int, long long)) foo;
fn (1, 1LL);
in one case and
void (*fn) (long long, int) = (void (*) (long long, int)) foo;
fn (1LL, 1);
in another, both folded into a direct call of foo with different
gimple_call_fntype. Sure, one of them would be UB at runtime (or both), but
what if we ICF merge it into something that into the one UB at runtime
and the program actually calls the correct one only?
2025-02-01 Jakub Jelinek <jakub@redhat.com>
PR ipa/117432
* ipa-icf-gimple.cc (func_checker::compare_asm_inputs_outputs):
Also return_false if operands have incompatible types.
(func_checker::compare_gimple_call): Check fntype1 vs. fntype2
compatibility for all non-internal calls and assume fntype1 and
fntype2 are non-NULL for those. For calls to non-prototyped
calls or for stdarg_p functions after the last named argument (if any)
check type compatibility of call arguments.
* gcc.c-torture/execute/pr117432.c: New test.
* gcc.target/i386/pr117432.c: New test.
Jakub Jelinek [Fri, 31 Jan 2025 10:02:41 +0000 (11:02 +0100)]
niter: Make build_cltz_expr more robust [PR118689]
Since my r15-7223 the niter analysis can recognize one loop during bootstrap
as being ctz like.
The patch just turned
@@ -2173,7 +2173,7 @@ PROC m2pim_NumberIO_BinToStr (CARDINAL x
_T535_44 = &buf[i.40_2]{lb: 1 sz: 4};
_T536_45 = x_21 & 1;
*_T535_44 = _T536_45;
- _T537_47 = x_21 / 2;
+ _T537_47 = x_21 >> 1;
x_48 = _T537_47;
# DEBUG x => x_48
if (x_48 != 0)
which is not a big deal for the number_of_iterations_cltz optimization, it
recognizes both right shift by 1 and unsigned division by 2 (and similarly
for clz left shift by 1 or multiplication by 2).
But starting with forwprop1 that change also resulted in
@@ -1875,9 +1875,9 @@ PROC m2pim_NumberIO_BinToStr (CARDINAL x
i.40_2 = (INTEGER) _T530_34;
_T536_45 = x_21 & 1;
MEM <CARDINAL[1:64]> [(CARDINAL *)&buf][i.40_2]{lb: 1 sz: 4} = _T536_45;
- _T537_47 = x_21 / 2;
+ _T537_47 = x_21 >> 1;
# DEBUG x => _T537_47
- if (x_21 > 1)
+ if (_T537_47 != 0)
goto <bb 3>; [INV]
else
goto <bb 8>; [INV]
and apparently it is only the latter form that number_of_iterations_cltz
pattern matches, not the former (after all, that was the exact reason
for r15-7223).
The problem is that build_cltz_expr assumes if IFN_C[LT]Z can't be used it
can use the __builtin_c[lt]z{,l,ll} builtins, and while most of the FEs do
create them, modula 2 does not.
The following patch just lets us punt if the FE doesn't build those builtins.
I've filed a PR against modula2 so that they add the builtins too.
2025-01-31 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/118689
PR modula2/115032
* tree-ssa-loop-niter.cc (build_cltz_expr): Return NULL_TREE if fn is
NULL and use_ifn is false.
Arsen Arsenović [Wed, 29 Jan 2025 20:14:33 +0000 (21:14 +0100)]
d: give dependency files better filenames [PR118477]
Currently, the dependency files for root-file.o and common-file.o were
both d/.deps/file.Po, which would cause parallel builds to fail
sometimes with:
make[3]: Leaving directory '/var/tmp/portage/sys-devel/gcc-14.1.1_p20240511/work/build/gcc'
make[3]: Entering directory '/var/tmp/portage/sys-devel/gcc-14.1.1_p20240511/work/build/gcc'
mv: cannot stat 'd/.deps/file.TPo': No such file or directory
make[3]: *** [/var/tmp/portage/sys-devel/gcc-14.1.1_p20240511/work/gcc-14-20240511/gcc/d/Make-lang.in:421: d/root-file.o] Error 1 shuffle=131581365
Also, this means that dependencies of one of root-file or common-file
are missing when developing. After this patch, those two files get
assigned dependency files d/.deps/root-file.Po and
d/.deps/common-file.Po respectively, so match the actual object
files in the d/ subdirectory.
There are other files with similar conflicts (mangle-package.o,
visitor-package.o for instance).
2025-01-29 Arsen Arsenović <arsen@aarsen.me>
Jakub Jelinek <jakub@redhat.com>
PR d/118477
* Make-lang.in (DCOMPILE, DPOSTCOMPILE): Use $(basename $(@F))
instead of $(*F).
Jakub Jelinek [Wed, 29 Jan 2025 08:32:04 +0000 (09:32 +0100)]
c++: Return false from __is_bounded_array for zero-sized arrays [PR118655]
This is basically Marek's PR114479 r14-9759 __is_array fix applied to
__is_bounded_array as well. Similarly to that trait, when not using
the builtin it returned false for zero sized arrays but when using
the builtin it returns true.
Jakub Jelinek [Tue, 28 Jan 2025 09:14:05 +0000 (10:14 +0100)]
combine: Fix up make_extraction [PR118638]
The following testcase is miscompiled at -Os on x86_64-linux.
The problem is during make_compound_operation of
(ashiftrt:SI (ashift:SI (mult:SI (reg:SI 107 [ a_5 ])
(const_int 3 [0x3]))
(const_int 31 [0x1f]))
(const_int 31 [0x1f]))
where it incorrectly returns
(mult:SI (sign_extract:SI (reg:SI 107 [ a_5 ])
(const_int 2 [0x2])
(const_int 0 [0]))
(const_int 3 [0x3]))
which isn't obviously true, the former returns either 0 or -1 depending
on the least significant bit of the multiplication,
the latter returns either 0 or -3 depending on the second least significant
bit of the multiplication argument.
The bug has been introduced in PR96998 r11-4563, which added handling of x
* (2^N) similar to x << N. In the above case, pos is 0 and len is 1,
sign extracting a single least significant bit of the multiplication.
As 3 is not a power of 2, shift_amt is -1.
But IN_RANGE (-1, 1, 1 - 1) is still true, because the basic requirement of
IN_RANGE that LOWER is not greater than UPPER is violated.
The intention of using 1 as LOWER is to avoid matching multiplication by 1,
that really shouldn't appear in the IL. But to avoid violating IN_RANGE
requirement, we need to verify that len is at least 2.
I've added this len > 1 check to the inner if rather than outer because I
think for GCC 16 we should add a further optimization.
In the particular case of 1 least significant bit sign extraction from
multiplication by 3, we could actually say it is equivalent to
(sign_extract:SI (reg:SI 107 [ a_5 ])
(const_int 1 [0x2])
(const_int 0 [0]))
That is because 3 is an odd number and multiplication by 2 will yield the
least significant bit 0 (we are sign extracting just one) and so the
multiplication doesn't change anything on the outcome.
More generally, even for larger len, multiplication by C which is
(1 << X) + 1 where X is >= len should be optimizable just to extraction
of the multiplicand's least significant len bits.
2025-01-28 Jakub Jelinek <jakub@redhat.com>
PR rtl-optimization/118638
* combine.cc (make_extraction): Only optimize (mult x 2^n) if len is
larger than 1.
Jakub Jelinek [Sat, 25 Jan 2025 09:15:24 +0000 (10:15 +0100)]
c++: Only destruct elts of array for new expression if exception is thrown during the initialization [PR117827]
The following testcase r12-6328, because the elements of the array
are destructed twice, once when the callee encounters delete[] p;
and then second time when the exception is thrown.
The array elts should be only destructed if exception is thrown from
one of the constructors during the build_vec_init emitted code in case of
new expressions, but when the new expression completes, it is IMO
responsibility of user code to delete[] it when it is no longer needed.
So, the following patch uses the cleanup_flags argument to build_vec_init
to get notified of the flags that need to be changed when the expression
is complete and build_disable_temp_cleanup to do the changes.
2025-01-25 Jakub Jelinek <jakub@redhat.com>
PR c++/117827
* init.cc (build_new_1): Pass address of a make_tree_vector ()
initialized gc tree vector to build_vec_init and append
build_disable_temp_cleanup to init_expr from it.
Jakub Jelinek [Thu, 23 Jan 2025 10:46:18 +0000 (11:46 +0100)]
tree-assume: Fix UB in assume_query [PR118605]
The assume_query constructor does
assume_query::assume_query (function *f, bitmap p) : m_parm_list (p),
m_func (f)
where m_parm_list is bitmap &. This is compile time UB, because
as soon as the constructor returns, m_parm_list reference is still
bound to the parameter of the constructor which is no longer in scope.
Now, one possible fix would be change the ctor argument to be bitmap &,
but that doesn't really work because in the only user of that class
we have
auto_bitmap decls;
...
assume_query query (fun, decls);
and auto_bitmap just has
operator bitmap () { return &m_bits; }
Could be perhaps const bitmap &, but why? bitmap is a pointer:
typedef class bitmap_head *bitmap;
and the EXECUTE_IF_SET_IN_BITMAP macros don't really change that point,
they just inspect what is inside of that bitmap_head the pointer points
to.
So, the simplest I think is avoid references (which cause even worse
code as it has to be dereferenced twice rather than once).
2025-01-23 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/118605
* tree-assume.cc (assume_query::m_parm_list): Change type
from bitmap & to bitmap.
projects / thirdparty / gcc.git / log
