Thomas Schwinge [Wed, 19 Feb 2025 19:34:25 +0000 (20:34 +0100)]
libstdc++: Avoid '-Wunused-parameter' for '__what' in function 'void std::__throw_format_error(const char*)'
In a '-fno-exceptions' configuration:
In file included from ../../../../../source-gcc/libstdc++-v3/src/c++20/format.cc:29:
[...]/build-gcc/[...]/libstdc++-v3/include/format: In function ‘void std::__throw_format_error(const char*)’:
[...]/build-gcc/[...]/libstdc++-v3/include/format:200:36: error: unused parameter ‘__what’ [-Werror=unused-parameter]
200 | __throw_format_error(const char* __what)
| ~~~~~~~~~~~~^~~~~~
The PR claims that pair-fusion has invalid uses of gcc_assert (such that
the pass will misbehave with --disable-checking). As noted in the
comments, in the case of the calls to restrict_movement, the only way we
can possibly depend on the side effects is if we call it with a
non-singleton move range. However, the intent is that we always have a
singleton move range here, and thus we do not rely on the side effects.
This patch therefore adds asserts to check for a singleton move range
before calling restrict_movement, thus clarifying the intent and
hopefully dispelling any concerns that having the calls wrapped in
asserts is problematic here.
gcc/ChangeLog:
PR rtl-optimization/114492
* pair-fusion.cc (pair_fusion_bb_info::fuse_pair): Check for singleton
move range before calling restrict_movement.
(pair_fusion::try_promote_writeback): Likewise.
libstdc++: implement tuple protocol for std::complex (P2819R2)
This commit implements P2819R2 for C++26, making std::complex
destructurable and tuple-like (see [complex.tuple]).
std::get needs to get forward declared in stl_pair.h (following the
existing precedent for the implementation of P2165R4, cf. r14-8710-g65b4cba9d6a9ff), and implemented in <complex>.
Also, std::get(complex<T>) needs to return *references* to the real and
imaginary parts of a std::complex object, honoring the value category
and constness of the argument. In principle a straightforward task, it
gets a bit convoluted by the fact that:
1) std::complex does not have existing getters that one can use for this
(real() and imag() return values, not references);
2) there are specializations for language/extended floating-point types,
which requires some duplication -- need to amend the primary and all
the specializations;
3) these specializations use a `__complex__ T`, but the primary template
uses two non-static data members, making generic code harder to write.
The implementation choice used here is to add the overloads of std::get
for complex as declared in [complex.tuple]. In turn they dispatch to a
newly added getter that extracts references to the real/imaginary parts
of a complex<T>. This getter is private API, and the implementation
depends on whether it's the primary (bind the data member) or a
specialization (use the GCC language extensions for __complex__).
To avoid duplication and minimize template instantiations, the getter
uses C++23's deducing this (this avoids const overloads). The value
category is dealt with by the std::get overloads.
Add a test that covers the aspects of the tuple protocol, as well as the
tuple-like interface. While at it, add a test for the existing
tuple-like feature-testing macro.
PR libstdc++/113310
libstdc++-v3/ChangeLog:
* include/bits/stl_pair.h (get): Forward-declare std::get for
std::complex.
* include/bits/version.def (tuple_like): Bump the value of
the feature-testing macro in C++26.
* include/bits/version.h: Regenerate.
* include/std/complex: Implement the tuple protocol for
std::complex.
(tuple_size): Specialize for std::complex.
(tuple_element): Ditto.
(__is_tuple_like_v): Ditto.
(complex): Add a private getter to obtain references to the real
and the imaginary part, on the primary class template and on its
specializations.
(get): Add overloads of std::get for std::complex.
* testsuite/20_util/tuple/tuple_like_ftm.cc: New test.
* testsuite/26_numerics/complex/tuple_like.cc: New test.
this patch removes TARGET_IRA_CALLEE_SAVED_REGISTER_COST_SCALE and
replaces it with two hooks: one that controls the cost of using an
extra callee-saved register and one that controls the cost of allocating
a frame for the first spill.
(The patch does not attempt to address the shrink-wrapping part of
the thread above.)
On AArch64, this is enough to fix PR117477, as verified by the new tests.
The patch does not change the SPEC2017 scores significantly. (I saw a
slight improvement in fotonik3d and roms, but I'm not convinced that
the improvements are real.)
The patch makes IRA use caller saves for gcc.target/aarch64/pr103350-1.c,
which is a scan-dump correctness test that relies on not using
caller saves. The decision to use caller saves looks appropriate,
and saves an instruction, so I've just added -fno-caller-saves
to the test options.
The x86 parts were written by Honza.
gcc/
PR rtl-optimization/117477
* config/aarch64/aarch64.cc (aarch64_count_saves): New function.
(aarch64_count_above_hard_fp_saves, aarch64_callee_save_cost)
(aarch64_frame_allocation_cost): Likewise.
(TARGET_CALLEE_SAVE_COST): Define.
(TARGET_FRAME_ALLOCATION_COST): Likewise.
* config/i386/i386.cc (ix86_ira_callee_saved_register_cost_scale):
Replace with...
(ix86_callee_save_cost): ...this new hook.
(TARGET_IRA_CALLEE_SAVED_REGISTER_COST_SCALE): Delete.
(TARGET_CALLEE_SAVE_COST): Define.
* target.h (spill_cost_type, frame_cost_type): New enums.
* target.def (callee_save_cost, frame_allocation_cost): New hooks.
(ira_callee_saved_register_cost_scale): Delete.
* doc/tm.texi.in (TARGET_IRA_CALLEE_SAVED_REGISTER_COST_SCALE): Delete.
(TARGET_CALLEE_SAVE_COST, TARGET_FRAME_ALLOCATION_COST): New hooks.
* doc/tm.texi: Regenerate.
* hard-reg-set.h (hard_reg_set_popcount): New function.
* ira-color.cc (allocated_memory_p): New variable.
(allocated_callee_save_regs): Likewise.
(record_allocation): New function.
(assign_hard_reg): Use targetm.frame_allocation_cost to model
the cost of the first spill or first caller save. Use
targetm.callee_save_cost to model the cost of using new callee-saved
registers. Apply the exit rather than entry frequency to the cost
of restoring a register or deallocating the frame. Update the
new variables above.
(improve_allocation): Use record_allocation.
(color): Initialize allocated_callee_save_regs.
(ira_color): Initialize allocated_memory_p.
* targhooks.h (default_callee_save_cost): Declare.
(default_frame_allocation_cost): Likewise.
* targhooks.cc (default_callee_save_cost): New function.
(default_frame_allocation_cost): Likewise.
Michal Jires [Thu, 6 Mar 2025 05:49:20 +0000 (06:49 +0100)]
lto: Fix missing cleanup with incremental LTO.
Incremental LTO disabled cleanup of output_files since they have to
persist in ltrans cache.
This unintetionally also kept temporary early debug "*.debug.temp.o"
files.
Bootstrapped/regtested on x86_64-linux.
Ok for trunk?
lto-plugin/ChangeLog:
* lto-plugin.c (cleanup_handler): Keep only files in ltrans
cache.
Richard Biener [Thu, 6 Mar 2025 08:08:07 +0000 (09:08 +0100)]
middle-end/119119 - re-gimplification of empty CTOR assignments
The following testcase runs into a re-gimplification issue during
inlining when processing
MEM[(struct e *)this_2(D)].a = {};
where re-gimplification does not handle assignments in the same
way than the gimplifier but instead relies on rhs_predicate_for
and gimplifying the RHS standalone. This fails to handle
special-casing of CTORs. The is_gimple_mem_rhs_or_call predicate
already handles clobbers but not empty CTORs so we end up in
the fallback code trying to force the CTOR into a separate stmt
using a temporary - but as we have a non-copyable type here that ICEs.
The following generalizes empty CTORs in is_gimple_mem_rhs_or_call
since those need no additional re-gimplification.
PR middle-end/119119
* gimplify.cc (is_gimple_mem_rhs_or_call): All empty CTORs
are OK when not a register type.
=== cut here ===
struct span {
span (const int (&__first)[1]) : _M_ptr (__first) {}
int operator[] (long __i) { return _M_ptr[__i]; }
const int *_M_ptr;
};
void foo () {
constexpr int a_vec[]{1};
auto vec{[&a_vec]() -> span { return a_vec; }()};
}
=== cut here ===
The problem is that perform_implicit_conversion_flags (via
mark_rvalue_use) replaces "a_vec" in the return statement by a
CONSTRUCTOR representing a_vec's constant value, and then takes its
address when invoking span's constructor. So we end up with an instance
that points to garbage instead of a_vec's storage.
As per Jason's suggestion, this patch simply removes the calls to
mark_*_use from perform_implicit_conversion_flags, which fixes the PR.
Jeff Law [Thu, 6 Mar 2025 05:24:05 +0000 (22:24 -0700)]
Improve coverage of ext-dce tests in risc-v testsuite
Inspired by Liao Shihua, this adjusts two tests in the RISC-V testsuite
to get more coverage. Drop the -O1 argument and replace it with -fext-dce.
That way the test gets run across the full set of flags. We just need to
make sure to skip -O0.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/core_list_init.c: Use -fext-dce rather than
-O1. Skip for -O0.
* gcc.target/riscv/pr111384.c: Ditto.
Gaius Mulley [Wed, 5 Mar 2025 23:01:45 +0000 (23:01 +0000)]
PR modula2/118998 Rotate of a packetset causes different types to binary operator error
This patch allow a packedset to be rotated by the system module intrinsic
procedure function. It ensures that both operands to the tree rotate are
of the same type. In turn the result will be the same type and the
assignment into the designator (of the same set type) will succeed.
gcc/m2/ChangeLog:
PR modula2/118998
* gm2-gcc/m2expr.cc (m2expr_BuildLRotate): Convert nBits
to the return type.
(m2expr_BuildRRotate): Ditto.
(m2expr_BuildLogicalRotate): Convert op3 to an integer type.
Replace op3 aith rotateCount.
Negate rotateCount if it is negative and call rotate right.
* gm2-gcc/m2pp.cc (m2pp_bit_and_expr): New function.
(m2pp_binary_function): Ditto.
(m2pp_simple_expression): BIT_AND_EXPR new case clause.
LROTATE_EXPR ditto.
RROTATE_EXPR ditto.
gcc/testsuite/ChangeLog:
PR modula2/118998
* gm2/iso/pass/testrotate.mod: New test.
* gm2/pim/fail/tinyconst.mod: New test.
* gm2/sets/run/pass/simplepacked.mod: New test.
Jonathan Wakely [Mon, 3 Mar 2025 13:36:54 +0000 (13:36 +0000)]
libstdc++: Move new functions to separate files [PR119110]
The new test functions I added in r15-7765-g3866ca796d5281 are causing
those tests to FAIL on Solaris and arm-thumb due to the linker
complaining about undefined functions. The new test functions are not
called, so it shouldn't matter that they call undefined member
functions, but it does.
Move those functions to separate { dg-do compile } files so the linker
isn't used and won't complain.
libstdc++-v3/ChangeLog:
PR libstdc++/119110
* testsuite/25_algorithms/move/constrained.cc: Move test06
function to ...
* testsuite/25_algorithms/move/105609.cc: New test.
* testsuite/25_algorithms/move_backward/constrained.cc: Move
test04 function to ...
* testsuite/25_algorithms/move_backward/105609.cc: New test.
This is a C++ >= 26 codepath for supporting constexpr stable_sort, so we
know that we have if consteval available; it just needs protection with
the feature-testing macro. Also merge the return in the same statement.
Amends r15-7708-gff43f9853d3b10.
libstdc++-v3/ChangeLog:
* include/bits/stl_algo.h (__stable_sort): Use if consteval
instead of is_constant_evaluated.
Jason Merrill [Wed, 5 Mar 2025 13:45:34 +0000 (08:45 -0500)]
c++: coroutines and return in registers [PR118874]
Because coroutines insert a call to the resumer between the initialization
of the return value and the actual return to the caller, we need to
duplicate the work of gimplify_return_expr for the !aggregate_value_p case.
PR c++/117364
PR c++/118874
gcc/cp/ChangeLog:
* coroutines.cc (cp_coroutine_transform::build_ramp_function): For
!aggregate_value_p return force return value into a local temp.
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.
Patrick Palka [Wed, 5 Mar 2025 16:11:35 +0000 (11:11 -0500)]
libstdc++: Some concat_view bugfixes [PR115215, PR115218, LWG 4082]
- Use __builtin_unreachable to suppress a false-positive "control
reaches end of non-void function" warning in the recursive lambda
(which the existing tests failed to notice since test01 wasn't
being called at runtime)
- Relax the constraints on views::concat in the single-argument case
as per PR115215
- Add an input_range requirement to that same case as per LWG 4082
- In the const-converting constructor of concat_view's iterator,
don't require the first iterator to be default constructible
PR libstdc++/115215
PR libstdc++/115218
libstdc++-v3/ChangeLog:
* include/std/ranges
(concat_view::iterator::_S_invoke_with_runtime_index): Use
__builtin_unreachable in recursive lambda to certify it always
exits via 'return'.
(concat_view::iterator::iterator): In the const-converting
constructor, direct initialize _M_it.
(views::_Concat::operator()): Adjust constraints in the
single-argument case as per LWG 4082.
* testsuite/std/ranges/concat/1.cc (test01): Call it at runtime
too.
(test04): New test.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com> Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Da Xie [Sun, 2 Mar 2025 06:45:11 +0000 (14:45 +0800)]
c++: Check invalid use of constrained auto with trailing return type [PR100589]
Add check for constrained auto type specifier in function declaration or
function type declaration with trailing return type. Issue error if such
usage is detected.
Test file renamed, and added a new test for type declaration.
Successfully bootstrapped and regretested on x86_64-pc-linux-gnu:
Added 6 passed and 4 unsupported tests.
PR c++/100589
gcc/cp/ChangeLog:
* decl.cc (grokdeclarator): Issue an error for a declarator with
constrained auto type specifier and trailing return types. Include
function names if available.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-pr100589.C: New test.
Signed-off-by: Da Xie <xxie_xd@163.com> Reviewed-by: Patrick Palka <ppalka@redhat.com> Reviewed-by: Jason Merrill <jason@redhat.com>
Kyrylo Tkachov [Wed, 5 Mar 2025 11:03:52 +0000 (03:03 -0800)]
PR rtl-optimization/119046: aarch64: Fix PARALLEL mode for vec_perm DUP expansion
The PARALLEL created in aarch64_evpc_dup is used to hold the lane number.
It is not appropriate for it to have a vector mode.
Other such uses use VOIDmode.
Do this here as well.
This avoids the risk of generic code treating the PARALLEL as trapping when it
has floating-point mode.
Bootstrapped and tested on aarch64-none-linux-gnu.
Signed-off-by: Kyrylo Tkachov <ktkachov@nvidia.com>
PR rtl-optimization/119046
* config/aarch64/aarch64.cc (aarch64_evpc_dup): Use VOIDmode for
PARALLEL.
Kyrylo Tkachov [Thu, 27 Feb 2025 17:00:25 +0000 (09:00 -0800)]
PR rtl-optimization/119046: Don't mark PARALLEL RTXes with floating-point mode as trapping
In this testcase late-combine was failing to merge:
dup v31.4s, v31.s[3]
fmla v30.4s, v31.4s, v29.4s
into the lane-wise fmla form.
This is because late-combine checks may_trap_p under the hood on the dup insn.
This ended up returning true for the insn:
(set (reg:V4SF 152 [ _32 ])
(vec_duplicate:V4SF (vec_select:SF (reg:V4SF 111 [ rhs_panel.8_31 ])
(parallel:V4SF [
(const_int 3 [0x3])]))))
Although mem_trap_p correctly reasoned that vec_duplicate and vec_select of
floating-point modes can't trap, it assumed that the V4SF parallel can trap.
The correct behaviour is to recurse into vector inside the PARALLEL and check
the sub-expression. This patch adjusts may_trap_p_1 to do just that.
With this check the above insn is not deemed to be trapping and is propagated
into the FMLA giving:
fmla vD.4s, vA.4s, vB.s[3]
Bootstrapped and tested on aarch64-none-linux-gnu.
Apparently this also fixes a regression in
gcc.target/aarch64/vmul_element_cost.c that I observed.
Jakub Jelinek [Wed, 5 Mar 2025 13:30:35 +0000 (14:30 +0100)]
value-range: Fix up irange::union_bitmask [PR118953]
The following testcase is miscompiled during evrp.
Before vrp, we have (from ccp):
# RANGE [irange] long long unsigned int [0, +INF] MASK 0xffffffffffffc000 VALUE 0x2d
_3 = _2 + 18446744073708503085;
...
# RANGE [irange] long long unsigned int [0, +INF] MASK 0xffffffffffffc000 VALUE 0x59
_6 = (long long unsigned int) _5;
# RANGE [irange] int [-INF, +INF] MASK 0xffffc000 VALUE 0x34
_7 = k_11 + -1048524;
switch (_7) <default: <L5> [33.33%], case 8: <L7> [33.33%], case 24: <L6> [33.33%], case 32: <L6> [33.33%]>
...
# RANGE [irange] long long unsigned int [0, +INF] MASK 0xffffffffffffc07d VALUE 0x0
# i_20 = PHI <_3(4), 0(3), _6(2)>
and evrp is now trying to figure out range for i_20 in range_of_phi.
All the ranges and MASK/VALUE pairs above are correct for the testcase,
k_11 and _2 based on it is a result of multiplication by a constant with low
14 bits cleared and then some numbers are added to it.
There is an obvious missed optimization for which I've filed PR119039,
simplify_switch_using_ranges could see that all the labels but default
are unreachable because the controlling expression has
MASK 0xffffc000 VALUE 0x34 and none of 8, 24 and 32 satisfy that.
Anyway, during range_of_phi for i_20, we process the PHI arguments
in order. For the _3(4) case, we figure out that it is reachable
through the case 24: case 32: labels only of the switch and that
0x34 - 0x2d is 7, so derive
[irange] long long unsigned int [17, 17][25, 25] MASK 0xffffffffffffc000 VALUE 0x2d
(the MASK/VALUE just got inherited from the _3 earlier range).
Now (not suprisingly because those labels aren't actually reachable),
that range is inconsistent, 0x2d is 45, so there is conflict between the
values and the irange_bitmask.
value-range.{h,cc} code differentiates between actually stored
irange_bitmask, which is that MASK 0xffffffffffffc000 VALUE 0x2d, and
semantic bitmask, which is what get_bitmask returns. That is
// The mask inherent in the range is calculated on-demand. For
// example, [0,255] does not have known bits set by default. This
// saves us considerable time, because setting it at creation incurs
// a large penalty for irange::set. At the time of writing there
// was a 5% slowdown in VRP if we kept the mask precisely up to date
// at all times. Instead, we default to -1 and set it when
// explicitly requested. However, this function will always return
// the correct mask.
//
// This also means that the mask may have a finer granularity than
// the range and thus contradict it. Think of the mask as an
// enhancement to the range. For example:
//
// [3, 1000] MASK 0xfffffffe VALUE 0x0
//
// 3 is in the range endpoints, but is excluded per the known 0 bits
// in the mask.
//
// See also the note in irange_bitmask::intersect.
irange_bitmask bm
= get_bitmask_from_range (type (), lower_bound (), upper_bound ());
if (!m_bitmask.unknown_p ())
bm.intersect (m_bitmask);
Now, get_bitmask_from_range here is MASK 0x1f VALUE 0x0 and it intersects
that with that MASK 0xffffffffffffc000 VALUE 0x2d.
Which triggers the ugly special case in irange_bitmask::intersect:
// If we have two known bits that are incompatible, the resulting
// bit is undefined. It is unclear whether we should set the entire
// range to UNDEFINED, or just a subset of it. For now, set the
// entire bitmask to unknown (VARYING).
if (wi::bit_and (~(m_mask | src.m_mask),
m_value ^ src.m_value) != 0)
{
unsigned prec = m_mask.get_precision ();
m_mask = wi::minus_one (prec);
m_value = wi::zero (prec);
}
so the semantic bitmask is actually MASK 0xffffffffffffffff VALUE 0x0.
Next, range_of_phi attempts to union it with the 0(3) PHI argument,
and during irange::union_ first adds the [0,0] to the subranges, so
[irange] long long unsigned int [0, 0][17, 17][25, 25] MASK 0xffffffffffffc000 VALUE 0x2d
and then goes on to irange::union_bitmask which does
if (m_bitmask == r.m_bitmask)
return false;
irange_bitmask bm = get_bitmask ();
irange_bitmask save = bm;
bm.union_ (r.get_bitmask ());
if (save == bm)
return false;
m_bitmask = bm;
if (save == get_bitmask ())
return false;
m_bitmask MASK 0xffffffffffffc000 VALUE 0x2d isn't the same as
r.m_bitmask MASK 0x0 VALUE 0x0, so we compute the semantic bitmask
(but note, not from the original range before union, but the modified one,
dunno if that isn't a problem as well), which is still the VARYING/unknown_p
one, union_ that with MASK 0x0 VALUE 0x0 and get still
MASK 0xffffffffffffffff VALUE 0x0, so don't update anything, the semantic
bitmask didn't change, so we are fine (not!, see later).
Except then we try to union with the third PHI argument. And, because the
edge to that comes only from case 8: label and there is a known difference
between the two, the argument is actually already from earlier replaced by
45(2) constant. So, irange::union_ adds the [45, 45] range to the list
of subranges, but voila, 45 is 0x2d and satisfies the stored
MASK 0xffffffffffffc000 VALUE 0x2d and so the semantic bitmask changed to
from MASK 0xffffffffffffffff VALUE 0x0 to MASK 0xffffffffffffc000 VALUE 0x2d
by that addition. Eventually, we just optimize this to
[irange] long long unsigned int [45, 45] because that is the only range
which satisfies the bitmask. And that is wrong, at runtime i_20 has
value 0.
The following patch attempts to detect this case where get_bitmask
turns some non-VARYING m_bitmask into VARYING one because of a conflict
and in that case makes sure m_bitmask is actually updated rather than
unmodified, so that later union_ doesn't cause problems.
I also wonder whether e.g. get_bitmask couldn't have special case for this
and if bm.intersect (m_bitmask); yields unknown_p from something not
originally unknown_p, perhaps chooses to just use get_bitmask_from_range
value and ignore the stored m_bitmask. Though, dunno how union_bitmask
in that case would figure out it needs to update m_bitmask.
2025-03-05 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/118953
* value-range.cc (irange::union_bitmask): Update m_bitmask if
get_bitmask () is unknown_p and m_bitmask is not even when the
semantic bitmask didn't change and returning false.
* 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
Richard Biener [Tue, 4 Mar 2025 15:13:09 +0000 (16:13 +0100)]
middle-end/97323 - TYPE_CANONICAL vs. ARRAY_TYPE modes
For strict-alignment targets we can end up with BLKmode single-element
array types when the element type is unaligned. This confuses
type checking since the canonical type would have an aligned
element type and a non-BLKmode mode. The following simply ignores
the mode we assign to array types for this purpose, like we already
do for record and union types.
PR middle-end/97323
* tree.cc (gimple_canonical_types_compatible_p): Ignore
TYPE_MODE also for ARRAY_TYPE.
(verify_type): Likewise.
This commit adds support for C++26's constexpr specialized memory
algorithms, introduced by P2283R2, P3508R0, P3369R0.
The uninitialized_default, value, copy, move and fill algorithms are
affected, in all of their variants (iterator-based, range-based and _n
versions.)
The changes are mostly mechanical -- add `constexpr` to a number of
signatures when compiling in C++26 and above modes. The internal helper
guard class for range algorithms instead can be marked unconditionally.
uninitialized_default_construct is implemented in terms of the
_Construct_novalue helper, which requires support for C++26's constexpr
placement new from the compiler (P2747R2, which GCC implements). We can
simply mark it as constexpr in C++26 language modes, even if the
compiler does not support P2747R2 (e.g. Clang 17/18), because C++23's
P2448R2 makes it OK to mark functions as constexpr even if they never
qualify, and other compilers implement this.
The only "real" change to the implementation of the algorithms is that
during constant evaluation I need to dispatch to a constexpr-friendly
version of them.
For each algorithm family I've added only one test to cover it and its
variants; the idea is to avoid too much repetition and simplify future
maintenance.
libstdc++-v3/ChangeLog:
* include/bits/ranges_uninitialized.h: Mark the specialized
memory algorithms as constexpr in C++26. Also mark the members
of the _DestroyGuard helper class.
* include/bits/stl_uninitialized.h: Ditto.
* include/bits/stl_construct.h: (_Construct_novalue) Mark it
as constexpr in C++26.
* include/bits/version.def (raw_memory_algorithms): Bump the
feature-testing macro for C++26.
* include/bits/version.h: Regenerate.
* testsuite/20_util/headers/memory/synopsis.cc: Add constexpr to
the uninitialized_* algorithms (when in C++26) in the test.
* testsuite/20_util/specialized_algorithms/feature_test_macro.cc:
New test.
* testsuite/20_util/specialized_algorithms/uninitialized_copy/constexpr.cc:
New test.
* testsuite/20_util/specialized_algorithms/uninitialized_default_construct/constexpr.cc:
New test.
* testsuite/20_util/specialized_algorithms/uninitialized_fill/constexpr.cc:
New test.
* testsuite/20_util/specialized_algorithms/uninitialized_move/constexpr.cc:
New test.
* testsuite/20_util/specialized_algorithms/uninitialized_value_construct/constexpr.cc:
New test.
Fortran: Add view convert to pointer assign when only pointer/alloc attr differs [PR104684]
PR fortran/104684
gcc/fortran/ChangeLog:
* trans-array.cc (gfc_conv_expr_descriptor): Look at the
lang-specific akind and do a view convert when only the akind
attribute differs between pointer and allocatable array.
Simon Martin [Wed, 5 Mar 2025 08:08:57 +0000 (09:08 +0100)]
c++: Fix checking assert upon invalid class definition [PR116740]
A checking assert triggers upon the following invalid code since
GCC 11:
=== cut here ===
class { a (struct b;
} struct b
=== cut here ===
The problem is that during error recovery, we call
set_identifier_type_value_with_scope for B in the global namespace, and
the checking assert added via r11-7228-g8f93e1b892850b fails.
This patch relaxes that assert to not fail if we've seen a parser error
(it a generalization of another fix done to that checking assert via r11-7266-g24bf79f1798ad1).
PR c++/116740
gcc/cp/ChangeLog:
* name-lookup.cc (set_identifier_type_value_with_scope): Don't
fail assert with ill-formed input.
Jakub Jelinek [Wed, 5 Mar 2025 06:47:52 +0000 (07:47 +0100)]
openmp, c++: Fix up OpenMP/OpenACC handling in C++ modules [PR119102]
modules.cc has apparently support for extensions and attempts to ensure
that if a module is compiled with those extensions enabled, sources which
use the module are compiled with the same extensions.
The only extension supported is SE_OPENMP right now.
And the use of the extension is keyed on streaming out or in OMP_CLAUSE
tree.
This is undesirable for several reasons.
OMP_CLAUSE is the only tree which can appear in the IL even without
-fopenmp/-fopenmp-simd/-fopenacc (when simd ("notinbranch") or
simd ("inbranch") attributes are used), and it can appear also in all
the 3 modes mentioned above. On the other side, with the exception of
arguments of attributes added e.g. for declare simd where no harm should
be done if -fopenmp/-fopenmp-simd isn't enabled later on, OMP_CLAUSE appears
in OMP_*_CLAUSES of OpenMP/OpenACC construct trees. And those construct
trees often have no clauses at all, so keying the extension on OMP_CLAUSE
doesn't catch many cases that should be caught.
Furthermore, for OpenMP we have 2 modes, -fopenmp-simd which parses some
OpenMP but constructs from that mostly OMP_SIMD and a few other cases,
and -fopenmp which includes that and far more on top of that; and there is
also -fopenacc.
So, this patch stops setting/requesting the extension on OMP_CLAUSE,
introduces 3 extensions rather than one (SE_OPENMP_SIMD, SE_OPENMP and
SE_OPENACC) and keyes those on OpenMP constructs from the -fopenmp-simd
subset, other OpenMP constructs and OpenACC constructs.
2025-03-05 Jakub Jelinek <jakub@redhat.com>
PR c++/119102
gcc/cp/
* module.cc (enum streamed_extensions): Add SE_OPENMP_SIMD
and SE_OPENACC, change value of SE_OPENMP and SE_BITS.
(CASE_OMP_SIMD_CODE, CASE_OMP_CODE, CASE_OACC_CODE): Define.
(trees_out::start): Don't set SE_OPENMP extension for OMP_CLAUSE.
Set SE_OPENMP_SIMD extension for CASE_OMP_SIMD_CODE, SE_OPENMP
for CASE_OMP_CODE and SE_OPENACC for CASE_OACC_CODE.
(trees_in::start): Don't fail for OMP_CLAUSE with missing
SE_OPENMP extension. Do fail for CASE_OMP_SIMD_CODE and missing
SE_OPENMP_SIMD extension, or CASE_OMP_CODE and missing SE_OPENMP
extension, or CASE_OACC_CODE and missing SE_OPENACC extension.
(module_state::write_readme): Write all of SE_OPENMP_SIMD, SE_OPENMP
and SE_OPENACC extensions.
(module_state::read_config): Diagnose missing -fopenmp, -fopenmp-simd
and/or -fopenacc depending on extensions used.
gcc/testsuite/
* g++.dg/modules/pr119102_a.H: New test.
* g++.dg/modules/pr119102_b.C: New test.
* g++.dg/modules/omp-3_a.C: New test.
* g++.dg/modules/omp-3_b.C: New test.
* g++.dg/modules/omp-3_c.C: New test.
* g++.dg/modules/omp-3_d.C: New test.
* g++.dg/modules/oacc-1_a.C: New test.
* g++.dg/modules/oacc-1_b.C: New test.
* g++.dg/modules/oacc-1_c.C: New test.
Jakub Jelinek [Wed, 5 Mar 2025 05:41:00 +0000 (06:41 +0100)]
c++: Apply/diagnose attributes when instatiating ARRAY/POINTER/REFERENCE_TYPE [PR118787]
The following testcase IMO in violation of the P2552R3 paper doesn't
pedwarn on alignas applying to dependent types or alignas with dependent
argument.
tsubst was just ignoring TYPE_ATTRIBUTES.
The following patch fixes it for the POINTER/REFERENCE_TYPE and
ARRAY_TYPE cases, but perhaps we need to do the same also for other
types (INTEGER_TYPE/REAL_TYPE and the like). I guess I'll need to
construct more testcases.
2025-03-05 Jakub Jelinek <jakub@redhat.com>
PR c++/118787
* pt.cc (tsubst) <case ARRAY_TYPE>: Use return t; only if it doesn't
have any TYPE_ATTRIBUTES. Call apply_late_template_attributes.
<case POINTER_TYPE, case REFERENCE_TYPE>: Likewise. Formatting fix.
Xi Ruoyao [Sun, 2 Mar 2025 11:02:50 +0000 (19:02 +0800)]
LoongArch: Fix incorrect reorder of __lsx_vldx and __lasx_xvldx [PR119084]
They could be incorrectly reordered with store instructions like st.b
because the RTL expression does not have a memory_operand or a (mem)
expression. The incorrect reorder has been observed in openh264 LTO
build.
Expand them to a (mem) expression instead of unspec to fix the issue.
Then we need to make loongarch_address_insns return 1 for
ADDRESS_REG_REG because the constraint "R" expects this behavior, or
the vldx instruction will be considered invalid by the register
allocate pass and turned to add.d + vld. Apply the ADDRESS_REG_REG
penalty in loongarch_address_cost instead, loongarch_rtx_costs should
also call loongarch_address_cost instead of loongarch_address_insns
then.
Thomas Koenig [Tue, 4 Mar 2025 19:13:19 +0000 (20:13 +0100)]
C prototypes for external arguments; add warning for mismatch.
The problem was that we were not handling external dummy arguments
with -fc-prototypes-external. In looking at this, I found that we
were not warning about external procedures with different argument
lists. This can actually be legal (see the two test cases) but
creates a problem for the C prototypes: If we have something like
subroutine foo(a,n)
external a
if (n == 1) call a(1)
if (n == 2) call a(2,3)
end subroutine foo
then, pre-C23, we could just have written out the prototype as
void foo_ (void (*a) (), int *n);
but this is illegal in C23. What to do? I finally chose to warn
about the argument mismatch, with a new option. Warn only because the
code above is legal, but include in -Wall because such code seems highly
suspect. This option is also implied in -fc-prototypes-external. I also
put a warning in the generated header file in that case, so users
have a chance to see what is going on (especially since gcc now
defaults to C23).
gcc/fortran/ChangeLog:
PR fortran/119049
PR fortran/119074
* dump-parse-tree.cc (seen_conflict): New static varaible.
(gfc_dump_external_c_prototypes): Initialize it. If it was
set, write out a warning that -std=c23 will not work.
(write_proc): Move the work of actually writing out the
formal arglist to...
(write_formal_arglist): New function. Handle external dummy
parameters and their argument lists. If there were mismatched
arguments, output an empty argument list in pre-C23 style.
* gfortran.h (struct gfc_symbol): Add ext_dummy_arglist_mismatch
flag and formal_at.
* invoke.texi: Document -Wexternal-argument-mismatch.
* lang.opt: Put it in.
* resolve.cc (resolve_function): If warning about external
argument mismatches, build a formal from actual arglist the
first time around, and later compare and warn.
(resolve_call): Likewise
gcc/testsuite/ChangeLog:
PR fortran/119049
PR fortran/119074
* gfortran.dg/interface_55.f90: New test.
* gfortran.dg/interface_56.f90: New test.
real 0m2.422s
user 0m2.421s
sys 0m0.000s
jh@shroud:~> sh bmk.sh blsmsk
real 0m0.973s
user 0m0.973s
sys 0m0.000s
real 0m2.422s
user 0m2.422s
sys 0m0.000s
We already have runable that controls tzcnt together with lzcnt and popcnt.
Since it seems that only tzcnt is affected I added new tunable to control tzcnt
only. I also added splitters for blsi/blsr/blsmsk implemented analogously to
existing splitter for lzcnt.
The patch is neutral on SPEC. We produce blsi and blsr in some internal loops, but
they usually have same destination as source. However it is good to break the
dependency chain to avoid patogolical cases and it is quite cheap overall, so I
think we want to enable this for generic. I will send followup patch for this.
Bootstrapped/regtested x86_64-linux, will commit it shortly.
gcc/ChangeLog:
* config/i386/i386.h (TARGET_AVOID_FALSE_DEP_FOR_TZCNT): New macro.
(TARGET_AVOID_FALSE_DEP_FOR_BLS): New macro.
* config/i386/i386.md (*bmi_blsi_<mode>): Add splitter for false
dependency.
(*bmi_blsi_<mode>_ccno): Add splitter for false dependency.
(*bmi_blsi_<mode>_falsedep): New pattern.
(*bmi_blsmsk_<mode>): Add splitter for false dependency.
(*bmi_blsmsk_<mode>_falsedep): New pattern.
(*bmi_blsr_<mode>): Add splitter for false dependency.
(*bmi_blsr_<mode>_cmp): Add splitter for false dependency
(*bmi_blsr_<mode>_cmp_falsedep): New pattern.
* config/i386/x86-tune.def (X86_TUNE_AVOID_FALSE_DEP_FOR_TZCNT): New tune.
(X86_TUNE_AVOID_FALSE_DEP_FOR_BLS): New tune.
gcc/testsuite/ChangeLog:
* gcc.target/i386/blsi.c: New test.
* gcc.target/i386/blsmsk.c: New test.
* gcc.target/i386/blsr.c: New test.
Jan Hubicka [Mon, 3 Mar 2025 18:12:20 +0000 (19:12 +0100)]
Make ix86_macro_fusion_pair_p and ix86_fuse_mov_alu_p match current CPUs
The current implementation of fussion predicates misses some common
fussion cases on zen and more recent cores. I added knobs for
individual conditionals we test.
1) I split checks for fusing ALU with conditional operands when the ALU
has memory operand. This seems to be supported by zen3+ and by
tigerlake and coperlake (according to Agner Fog's manual)
2) znver4 and 5 supports fussion of ALU and conditional even if ALU has
memory and immediate operands.
This seems to be relatively important enabling 25% more fusions on
gcc bootstrap.
3) no CPU supports fusing when ALU contains IP relative memory
references. I added separate knob so we do not forger about this if
this gets supoorted later.
The patch does not solve the limitation of sched that fuse pairs must be
adjacent on imput and the first operation must be signle-set. Fixing
single-set is easy (I have separate patch for this), for non-adjacent
pairs we need bigger surgery.
To verify what CPU really does I made simpe test script.
jh@ryzen3:~> cat fuse-test.c
int b;
const int z = 0;
const int o = 1;
int
main()
{
int a = 1000000000;
int b;
int z = 0;
int o = 1;
asm volatile ("\n"
".L1234:\n"
"nop\n"
"subl %3, %0\n"
echo ALU with immediate
dotest
echo ALU with memory
dotest -D MEM
echo ALU with IP relative memory
dotest -D MEM -D IPRELATIVE
echo CMP with immediate
dotest -D CMP
echo CMP with memory
dotest -D CMP -D MEM
echo CMP with memory and immediate
dotest -D CMP -D MEMIMM
echo CMP with IP relative memory
dotest -D CMP -D MEM -D IPRELATIVE
echo TEST
dotest -D TEST
On zen5 I get:
ALU with immediate
20,345 ex_ret_fused_instr:u
1,000,020,278 ex_ret_fused_instr:u
ALU with memory
20,367 ex_ret_fused_instr:u
1,000,020,290 ex_ret_fused_instr:u
ALU with IP relative memory
20,395 ex_ret_fused_instr:u
20,403 ex_ret_fused_instr:u
CMP with immediate
20,369 ex_ret_fused_instr:u
1,000,020,301 ex_ret_fused_instr:u
CMP with memory
20,314 ex_ret_fused_instr:u
1,000,020,341 ex_ret_fused_instr:u
CMP with memory and immediate
20,372 ex_ret_fused_instr:u
1,000,020,266 ex_ret_fused_instr:u
CMP with IP relative memory
20,382 ex_ret_fused_instr:u
20,369 ex_ret_fused_instr:u
TEST
20,346 ex_ret_fused_instr:u
1,000,020,301 ex_ret_fused_instr:u
IP relative memory seems to not be documented.
On zen3/4 I get:
ALU with immediate
20,263 ex_ret_fused_instr:u
1,000,020,051 ex_ret_fused_instr:u
ALU with memory
20,255 ex_ret_fused_instr:u
1,000,020,056 ex_ret_fused_instr:u
ALU with IP relative memory
20,253 ex_ret_fused_instr:u
20,266 ex_ret_fused_instr:u
CMP with immediate
20,264 ex_ret_fused_instr:u
1,000,020,052 ex_ret_fused_instr:u
CMP with memory
20,253 ex_ret_fused_instr:u
1,000,019,794 ex_ret_fused_instr:u
CMP with memory and immediate
20,260 ex_ret_fused_instr:u
20,264 ex_ret_fused_instr:u
CMP with IP relative memory
20,258 ex_ret_fused_instr:u
20,256 ex_ret_fused_instr:u
TEST
20,261 ex_ret_fused_instr:u
1,000,020,048 ex_ret_fused_instr:u
zen1 and 2 gets:
ALU with immediate
21,610 ex_ret_fus_brnch_inst:u
21,697 ex_ret_fus_brnch_inst:u
ALU with memory
21,479 ex_ret_fus_brnch_inst:u
21,747 ex_ret_fus_brnch_inst:u
ALU with IP relative memory
21,623 ex_ret_fus_brnch_inst:u
21,684 ex_ret_fus_brnch_inst:u
CMP with immediate
21,708 ex_ret_fus_brnch_inst:u
1,000,021,288 ex_ret_fus_brnch_inst:u
CMP with memory
21,689 ex_ret_fus_brnch_inst:u
1,000,004,270 ex_ret_fus_brnch_inst:u
CMP with memory and immediate
21,604 ex_ret_fus_brnch_inst:u
21,671 ex_ret_fus_brnch_inst:u
CMP with IP relative memory
21,589 ex_ret_fus_brnch_inst:u
21,602 ex_ret_fus_brnch_inst:u
TEST
21,600 ex_ret_fus_brnch_inst:u
1,000,021,233 ex_ret_fus_brnch_inst:u
I tested the patch on zen3 and zen5 and spec2k17 and it seems neutral, however
the number of fussion does go up.
Bootstrapped/regtested x86_64-linux, I plan to commit it tomorrow.
Honza
gcc/ChangeLog:
* config/i386/i386.h (TARGET_FUSE_ALU_AND_BRANCH_MEM): New macro.
(TARGET_FUSE_ALU_AND_BRANCH_MEM_IMM): New macro.
(TARGET_FUSE_ALU_AND_BRANCH_RIP_RELATIVE): New macro.
* config/i386/x86-tune-sched.cc (ix86_fuse_mov_alu_p): Support
non-single-set.
(ix86_macro_fusion_pair_p): Allow ALU which only clobbers;
be more careful about immediates; check TARGET_FUSE_ALU_AND_BRANCH_MEM,
TARGET_FUSE_ALU_AND_BRANCH_MEM_IMM, TARGET_FUSE_ALU_AND_BRANCH_RIP_RELATIVE;
verify that we never use unsigned checks with inc/dec.
* config/i386/x86-tune.def (X86_TUNE_FUSE_ALU_AND_BRANCH): New tune.
(X86_TUNE_FUSE_ALU_AND_BRANCH_MEM): New tune.
(X86_TUNE_FUSE_ALU_AND_BRANCH_MEM_IMM): New tune.
(X86_TUNE_FUSE_ALU_AND_BRANCH_RIP_RELATIVE): New tune.
which output_constructor_regular_field doesn't want to see. This
happens since r9-1483: process_init_constructor_array can now create
a RANGE_EXPR. But the bug isn't in that patch; the problem is that
build_vec_init doesn't handle RANGE_EXPRs.
build_vec_init has a FOR_EACH_CONSTRUCTOR_ELT loop which populates
const_vec. In this case it loops over the elements of
{[0 ... 1]={.low=0, .high=1}}
but assumes that each element initializes one element. So after the
loop num_initialized_elts was 1, and then below:
HOST_WIDE_INT last = tree_to_shwi (maxindex);
if (num_initialized_elts <= last)
{
tree field = size_int (num_initialized_elts);
if (num_initialized_elts != last)
field = build2 (RANGE_EXPR, sizetype, field,
size_int (last));
CONSTRUCTOR_APPEND_ELT (const_vec, field, e);
}
we added the extra initializer.
It seemed convenient to use range_expr_nelts like below.
PR c++/109431
gcc/cp/ChangeLog:
* cp-tree.h (range_expr_nelts): Declare.
* init.cc (build_vec_init): If the CONSTRUCTOR's index is a
RANGE_EXPR, use range_expr_nelts to count how many elements
were initialized.
Tamar Christina [Tue, 4 Mar 2025 11:15:26 +0000 (11:15 +0000)]
aarch64: force operand to fresh register to avoid subreg issues [PR118892]
When the input is already a subreg and we try to make a paradoxical
subreg out of it for copysign this can fail if it violates the subreg
relationship.
Use force_lowpart_subreg instead of lowpart_subreg to then force the
results to a register instead of ICEing.
gcc/ChangeLog:
PR target/118892
* config/aarch64/aarch64.md (copysign<GPF:mode>3): Use
force_lowpart_subreg instead of lowpart_subreg.
gcc/testsuite/ChangeLog:
PR target/118892
* gcc.target/aarch64/copysign-pr118892.c: New test.
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.
The simplify_logical_relational_operation code (in its current form)
was written with arithmetic rather than CC modes in mind. Since CCFP
is a CC mode, it fails the HONOR_NANS check, and so the function assumes
that ge | lt => true.
If one comparison is unsigned then it should be safe to assume that
the other comparison is also unsigned, even for CC modes, since the
optimisation checks that the comparisons are between the same operands.
For the other cases, we can only safely fold comparisons of CC mode
values if the result is always-true (15) or always-false (0).
It turns out that the original testcase for PR117186, which ran at -O,
was relying on the old behaviour for some of the functions. It needs
4-instruction combinations, and so -fexpensive-optimizations, to pass
in its intended form.
gcc/
PR rtl-optimization/119002
* simplify-rtx.cc
(simplify_context::simplify_logical_relational_operation): Handle
comparisons between CC values. If there is no evidence that the
CC values are unsigned, restrict the fold to always-true or
always-false results.
gcc/testsuite/
* gcc.c-torture/execute/ieee/pr119002.c: New test.
* gcc.target/aarch64/pr117186.c: Run at -O2 rather than -O.
When we vectorize a .COND_ADD reduction and apply the single-use-def
cycle optimization we can end up chosing the wrong else value for
subsequent .COND_ADD. The following rectifies this.
PR tree-optimization/119096
* tree-vect-loop.cc (vect_transform_reduction): Use the
correct else value for .COND_fn.
Pan Li [Mon, 3 Mar 2025 06:51:21 +0000 (14:51 +0800)]
RISC-V: Fix the test case bug-3.c failure
The bug-3.c would like to check the slli a[0-9]+, a[0-9]+, 33 for the
big poly int handling. But the underlying insn may change to slli 1
+ slli 32 with sorts of optimization. Thus, update the asm check to
function body check with above slli 1 + slli 32 series.
The below test suites are passed for this patch.
* The rv64gcv fully regression test.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/bug-3.c: Update asm check to
function body check.
Harald Anlauf [Sun, 2 Mar 2025 21:20:28 +0000 (22:20 +0100)]
Fortran: reject empty derived type with bind(C) attribute [PR101577]
PR fortran/101577
gcc/fortran/ChangeLog:
* symbol.cc (verify_bind_c_derived_type): Generate error message
for derived type with no components in standard conformance mode,
indicating that this is a GNU extension.
gcc/testsuite/ChangeLog:
* gfortran.dg/empty_derived_type.f90: Adjust dg-options.
* gfortran.dg/empty_derived_type_2.f90: New test.
Andrew Carlotti [Fri, 7 Feb 2025 17:13:36 +0000 (17:13 +0000)]
aarch64: Ignore target pragmas while defining intrinsics
Refactor the switcher classes into two separate classes:
- sve_alignment_switcher takes the alignment switching functionality,
and is used only for ABI correctness when defining sve structure
types.
- aarch64_target_switcher takes the rest of the functionality of
aarch64_simd_switcher and sve_switcher, and gates simd/sve specific
parts upon the specified feature flags.
Additionally, aarch64_target_switcher now adds dependencies of the
specified flags (which adds +fcma and +bf16 to some intrinsic
declarations), and unsets current_target_pragma.
This last change fixes an internal bug where we would sometimes add a
user specified target pragma (stored in current_target_pragma) on top of
an internally specified target architecture while initialising
intrinsics with `#pragma GCC aarch64 "arm_*.h"`. As far as I can tell, this
has no visible impact at the moment. However, the unintended target
feature combinations lead to unwanted behaviour in an under-development
patch.
This also fixes a missing Makefile dependency, which was due to
aarch64-sve-builtins.o incorrectly depending on the undefined $(REG_H).
The correct $(REGS_H) dependency is added to the switcher's new source
location.
gcc/ChangeLog:
* common/config/aarch64/aarch64-common.cc
(struct aarch64_extension_info): Add field.
(aarch64_get_required_features): New.
* config/aarch64/aarch64-builtins.cc
(aarch64_simd_switcher::aarch64_simd_switcher): Rename to...
(aarch64_target_switcher::aarch64_target_switcher): ...this,
and extend to handle sve, nosimd and target pragmas.
(aarch64_simd_switcher::~aarch64_simd_switcher): Rename to...
(aarch64_target_switcher::~aarch64_target_switcher): ...this,
and extend to handle sve, nosimd and target pragmas.
(handle_arm_acle_h): Use aarch64_target_switcher.
(handle_arm_neon_h): Rename switcher and pass explicit flags.
(aarch64_general_init_builtins): Ditto.
* config/aarch64/aarch64-protos.h
(class aarch64_simd_switcher): Rename to...
(class aarch64_target_switcher): ...this, and add new members.
(aarch64_get_required_features): New prototype.
* config/aarch64/aarch64-sve-builtins.cc
(sve_switcher::sve_switcher): Delete
(sve_switcher::~sve_switcher): Delete
(sve_alignment_switcher::sve_alignment_switcher): New
(sve_alignment_switcher::~sve_alignment_switcher): New
(register_builtin_types): Use alignment switcher
(init_builtins): Rename switcher.
(handle_arm_neon_sve_bridge_h): Ditto.
(handle_arm_sme_h): Ditto.
(handle_arm_sve_h): Ditto, and use alignment switcher.
* config/aarch64/aarch64-sve-builtins.h
(class sve_switcher): Delete.
(class sme_switcher): Delete.
(class sve_alignment_switcher): New.
* config/aarch64/t-aarch64 (aarch64-builtins.o): Add $(REGS_H).
(aarch64-sve-builtins.o): Remove $(REG_H).
arm: remove some redundant zero_extend ops on thumb1
The code in gcc.target/unsigned-extend-1.c really should not need an
unsigned extension operations when the optimizers are used. For Arm
and thumb2 that is indeed the case, but for thumb1 code it gets more
complicated as there are too many instructions for combine to look at.
For thumb1 we end up with two redundant zero_extend patterns which are
not removed: the first after the subtract instruction and the second of
the final boolean result.
We can partially fix this (for the second case above) by adding a new
split pattern for LEU and GEU patterns which work because the two
instructions for the [LG]EU pattern plus the redundant extension
instruction are combined into a single insn, which we can then split
using the 3->2 method back into the two insns of the [LG]EU sequence.
Because we're missing the optimization for all thumb1 cases (not just
those architectures with UXTB), I've adjust the testcase to detect all
the idioms that we might use for zero-extending a value, namely:
UXTB
AND ...#255 (in thumb1 this would require a register to hold 255)
LSL ... #24; LSR ... #24
but I've also marked this test as XFAIL for thumb1 because we can't yet
eliminate the first of the two extend instructions.
gcc/
* config/arm/thumb1.md (split patterns for GEU and LEU): New.
gcc/testsuite:
* gcc.target/arm/unsigned-extend-1.c: Expand check for any
insn suggesting a zero-extend. XFAIL for thumb1 code.
--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 [Mon, 3 Mar 2025 13:53:03 +0000 (14:53 +0100)]
ipa-vr: Handle non-conversion unary ops separately from conversions (PR 118785)
Since we construct arithmetic jump functions even when there is a
type conversion in between the operation encoded in the jump function
and when it is passed in a call argument, the IPA propagation phase
must also perform the operation and conversion in two steps. IPA-VR
had actually been doing it even before for binary operations but, as
PR 118756 exposes, not in the case on unary operations. This patch
adds the necessary step to rectify that.
Like in the scalar constant case, we depend on
expr_type_first_operand_type_p to determine the type of the result of
the arithmetic operation. On top this, the patch special-cases
ABSU_EXPR because it looks useful an so that the PR testcase exercises
the added code-path. This seems most appropriate for stage 4, long
term we should probably stream the types, probably after also encoding
them with a string of expr_eval_op rather than what we have today.
A check for expr_type_first_operand_type_p was also missing in the
handling of binary ops and the intermediate value_range was
initialized with a wrong type, so I also fixed this.
gcc/ChangeLog:
2025-02-24 Martin Jambor <mjambor@suse.cz>
PR ipa/118785
* ipa-cp.cc (ipa_vr_intersect_with_arith_jfunc): Handle non-conversion
unary operations separately before doing any conversions. Check
expr_type_first_operand_type_p for non-unary operations too. Fix type
of op_res.
gcc/testsuite/ChangeLog:
2025-02-24 Martin Jambor <mjambor@suse.cz>
PR ipa/118785
* g++.dg/lto/pr118785_0.C: New test.
We are detecting a cycle as double reduction where the inner loop
cycle has extra out-of-loop uses. This clashes at least with
assumptions from the SLP discovery code which says the cycle
isn't reachable from another SLP instance. It also was not intended
to support this case, in fact with GCC 14 we seem to generate wrong
code here.
PR tree-optimization/119057
* tree-vect-loop.cc (check_reduction_path): Add argument
specifying whether we're analyzing the inner loop of a
double reduction. Do not allow extra uses outside of the
double reduction cycle in this case.
(vect_is_simple_reduction): Adjust.
Richard Biener [Mon, 3 Mar 2025 08:54:15 +0000 (09:54 +0100)]
ipa/119067 - bogus TYPE_PRECISION check on VECTOR_TYPE
odr_types_equivalent_p can end up using TYPE_PRECISION on vector
types which is a no-go. The following instead uses TYPE_VECTOR_SUBPARTS
for vector types so we also end up comparing the number of vector elements.
PR ipa/119067
* ipa-devirt.cc (odr_types_equivalent_p): Check
TYPE_VECTOR_SUBPARTS for vectors.
* g++.dg/lto/pr119067_0.C: New testcase.
* g++.dg/lto/pr119067_1.C: Likewise.
Fortran: Fix regression on double free on elemental function [PR118747]
Fix a regression were adding a temporary variable inserted a copy of the
argument to the elemental function. That copy was then later used to
free allocated memory, but the freeing was not tracked in the source
array correctly.
PR fortran/118747
gcc/fortran/ChangeLog:
* trans-array.cc (gfc_trans_array_ctor_element): Remove copy to
temporary variable.
* trans-expr.cc (gfc_conv_procedure_call): Use references to
array members instead of copies when freeing after use.
Formatting fix.
gcc/testsuite/ChangeLog:
* gfortran.dg/alloc_comp_auto_array_4.f90: New test.
Jeff Law [Sun, 2 Mar 2025 19:08:34 +0000 (12:08 -0700)]
[RISC-V][PR target/118934] Fix ICE in RISC-V long branch support
I'm not sure if I goof'd this or if I merely upstreamed someone else's goof.
Either way the long branch code isn't working correctly.
We were using 'n' as the output modifier to negate the condition. But 'n' has
a special meaning elsewhere, so when presented with a condition rather than
what was expected, boom, the compiler ICE'd.
Thankfully there's only a few places where we were using %n which I turned into
%r.
The BZ entry includes a good testcase, it just takes a long time to compile as
it's trying to create the out-of-range scenario. I'm not including the
testcase due to how long it takes, but I did test it locally to ensure it's
working properly now.
I'm sure that with a little bit of work I could create at testcase that worked
before and fails with the trunk (by taking advantage of the fuzzyness in length
computations). So I'm going to consider this a regression.
Will push to the trunk after pre-commit testing does its thing.
Sandra Loosemore [Tue, 25 Feb 2025 20:39:31 +0000 (20:39 +0000)]
Fortran: Move "Standard" subheading in documentation [PR47928]
As noted in the issue, the version of the standard an intrinsic was
introduced in is usually not the second-most-important thing a user
needs to know. This patch moves it from near the beginning of each
section towards the end, just ahead of "See also".
Sandra Loosemore [Tue, 25 Feb 2025 23:39:25 +0000 (23:39 +0000)]
Fortran: Rename/move "Syntax" subheading in documentation [PR47928]
As suggested in the issue, it makes more sense to describe the function
call argument syntax before talking about the arguments in the description.
gcc/fortran/ChangeLog
PR fortran/47928
* gfortran.texi: Move all the "Syntax" subheadings ahead of
"Description", and rename to "Synopsis".
* intrinsic.texi: Likewise.
Sandra Loosemore [Tue, 25 Feb 2025 01:03:52 +0000 (01:03 +0000)]
Fortran: Tidy subheadings in Fortran documentation [PR47928]
This is a preparatory patch for the main documentation changes requested
in the issue.
gcc/fortran/ChangeLog
PR fortran/47928
* gfortran.texi: Consistently use "@emph{Notes}:" instead of
other spellings.
* intrinsic.texi: Likewise. Also fix an inconsistent capitalization
and remove a redundant "Standard" entry.
Jakub Jelinek [Sun, 2 Mar 2025 10:30:35 +0000 (11:30 +0100)]
avr: Fix up avr_print_operand diagnostics [PR118991]
As can be seen in gcc/po/gcc.pot:
#: config/avr/avr.cc:2754
#, c-format
msgid "bad I/O address 0x"
msgstr ""
exgettext couldn't retrieve the whole format string in this case,
because it uses a macro in the middle. output_operand_lossage
is c-format function though, so we can't use %wx to print HOST_WIDE_INT,
and HOST_WIDE_INT_PRINT_HEX_PURE is on some hosts %lx, on others %llx
and on others %I64x so isn't really translatable that way.
As Joseph mentioned in the PR, there is no easy way around this
but go through a temporary buffer, which the following patch does.
2025-03-02 Jakub Jelinek <jakub@redhat.com>
PR translation/118991
* config/avr/avr.cc (avr_print_operand): Print ival into
a temporary buffer and use %s in output_operand_lossage to make
the diagnostics translatable.
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.
Jakub Jelinek [Sat, 1 Mar 2025 19:48:16 +0000 (20:48 +0100)]
ggc: Fix up ggc_internal_cleared_alloc_no_dtor [PR117047]
Apparently I got one of the !HAVE_ATTRIBUTE_ALIAS fallbacks wrong.
It compiled with a warning:
../../gcc/ggc-common.cc: In function 'void* ggc_internal_cleared_alloc_no_dtor(size_t, void (*)(void*), size_t, size_t)':
../../gcc/ggc-common.cc:154:44: warning: unused parameter 'size' [-Wunused-parameter]
154 | ggc_internal_cleared_alloc_no_dtor (size_t size, void (*f)(void *),
| ~~~~~~~^~~~
and obviously didn't work right (always allocated 0-sized objects).
Fixed thusly.
2025-03-01 Jakub Jelinek <jakub@redhat.com>
PR jit/117047
* ggc-common.cc (ggc_internal_cleared_alloc_no_dtor): Pass size
rather than s as the first argument to ggc_internal_cleared_alloc.
Yuriy Kolerov [Sat, 1 Mar 2025 15:35:55 +0000 (08:35 -0700)]
[PR target/118906] [PATCH v2] RISC-V: Fix a typo in zce to zcf implication
zce must imply zcf but this rule was corrupted after
refactoring in 9e12010b5e724277ea. This may be observed
ater generating an .s file from any source code file with
-mriscv-attribute -march=rv32if_zce -mabi=ilp32 -S
options. A full march will be presented in arch attribute:
As you see, zcf is not presented here though f_zce pair is
passed in -march. According to The RISC-V Instruction
Set Manual:
Specifying Zce on RV32 with F includes Zca, Zcb, Zcmp,
Zcmt and Zcf.
PR target/118906
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc: fix zce to zcf
implication.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/attribute-zce-1.c: New test.
* gcc.target/riscv/attribute-zce-2.c: New test.
* gcc.target/riscv/attribute-zce-3.c: New test.
* gcc.target/riscv/attribute-zce-4.c: New test.
Jan Dubiec [Sat, 1 Mar 2025 15:21:16 +0000 (08:21 -0700)]
[PATCH] H8/300, libgcc: PR target/114222 For HImode call internal ffs() implementation instead of an external one
When INT_TYPE_SIZE < BITS_PER_WORD gcc emits a call to an external ffs()
implementation instead of a call to "__builtin_ffs()" – see function
init_optabs() in <SRCROOT>/gcc/optabs-libfuncs.cc. External ffs()
(which is usually the one from newlib) in turn calls __builtin_ffs()
what causes infinite recursion and stack overflow. This patch overrides
default gcc bahaviour for H8/300H (and newer) and provides a generic
ffs() implementation for HImode.
PR target/114222
gcc/ChangeLog:
* config/h8300/h8300.cc (h8300_init_libfuncs): For HImode override
calls to external ffs() (from newlib) with calls to __ffshi2() from
libgcc. The implementation of ffs() in newlib calls __builtin_ffs()
what causes infinite recursion and finally a stack overflow.
libgcc/ChangeLog:
* config/h8300/t-h8300: Add __ffshi2().
* config/h8300/ffshi2.c: New file.
Jakub Jelinek [Sat, 1 Mar 2025 15:09:07 +0000 (16:09 +0100)]
input: Fix UB during self-tests [PR119052]
As the comment in check_line says:
/* get_buffer is not null terminated, but the sscanf stops after a number. */
the buffer is not null terminated, there is line.length () to determine
the size of the line. But unlike what the comment says, sscanf actually
still requires null terminated string argument, anything else is UB.
E.g. glibc when initializing the temporary FILE stream for the string does
if (size == 0)
end = strchr (ptr, '\0');
and this strchr/rawmemchr is what shows up in valgrind report on cc1/cc1plus
doing self-tests.
The function is used only in a test with 1000 lines, each containg its
number, so numbers from 1 to 1000 inclusive (each time with '\n' separator,
but that isn't included in line.length ()).
So the function just uses a temporary buffer which can fit numbers from 1 to
1000 as strings with terminating '\0' and runs sscanf on that (why not
strtoul?).
Furthermore, the caller allocated number of lines * 15 bytes for the
string, but 1000\n is 5 bytes, so I think * 5 is more than enough.
2025-03-01 Jakub Jelinek <jakub@redhat.com>
PR other/119052
* input.cc (check_line): Don't call sscanf on non-null terminated
buffer, instead copy line.length () bytes from line.get_buffer ()
to a local buffer, null terminate it and call sscanf on that.
Formatting fix.
(test_replacement): Just allocate maxline * 5 rather than maxline * 15
bytes for the file. Formatting fix.
Jakub Jelinek [Sat, 1 Mar 2025 10:22:27 +0000 (11:22 +0100)]
ggc: Avoid using ATTRIBUTE_MALLOC for allocations that need finalization [PR117047]
As analyzed by Andrew/David/Richi/Sam in the PR, the reason for the
libgccjit ICE is that there are GC allocations with finalizers and we
still mark ggc_internal_{,cleared_}alloc with ATTRIBUTE_MALLOC, which
to the optimizers hints that nothing will actually read the state
of the objects when they get out of lifetime. The finalizer actually
inspects those though. What actually happens in the testcases is that on
tree expr_size = TYPE_SIZE (expr->get_type ()->as_tree ());
we see that expr->get_type () was allocated using something with malloc
attribute but it doesn't escape and only the type size from it is queried,
so there is no need to store other members of it. Except that it does escape
in the GC internals. Normal GC allocations are fine, they don't look at the
data in the allocated objects on "free", but the ones with finalizers actually
call a function on that object and expect the data to be in there.
So that we don't lose ATTRIBUTE_MALLOC for the common case when no
finalization is needed, the following patch uses the approach used e.g.
for glibc error function which can sometimes be noreturn but at other
times just return normally.
If possible, it uses __attribute__((alias ("..."))) to add an alias
to the function, where one is without ATTRIBUTE_MALLOC and one
(with _no_dtor suffix) is with ATTRIBUTE_MALLOC (note, as this is
C++ and I didn't want to hardcode particular mangling I used an
extern "C" function with 2 aliases to it), and otherwise adds a wrapper
(for the ggc-page/ggc-common case with noinline attribute if possible,
for ggc-none that doesn't matter because ggc-none doesn't support
finalizers).
The *_no_dtor aliases/wrappers are then used in inline functions which
pass unconditional NULL, 0 as the f/s pair.
2025-03-01 Jakub Jelinek <jakub@redhat.com>
PR jit/117047
* acinclude.m4 (gcc_CHECK_ATTRIBUTE_ALIAS): New.
* configure.ac: Add gcc_CHECK_ATTRIBUTE_ALIAS.
* ggc.h (ggc_internal_alloc): Remove ATTRIBUTE_MALLOC from
overload with finalizer pointer. Call ggc_internal_alloc_no_dtor
in inline overload without finalizer pointer.
(ggc_internal_alloc_no_dtor): Declare.
(ggc_internal_cleared_alloc): Remove ATTRIBUTE_MALLOC from
overload with finalizer pointer. Call
ggc_internal_cleared_alloc_no_dtor in inline overload without
finalizer pointer.
(ggc_internal_cleared_alloc_no_dtor): Declare.
(ggc_alloc): Call ggc_internal_alloc_no_dtor if no finalization
is needed.
(ggc_alloc_no_dtor): Call ggc_internal_alloc_no_dtor.
(ggc_cleared_alloc): Call ggc_internal_cleared_alloc_no_dtor if no
finalization is needed.
(ggc_vec_alloc): Call ggc_internal_alloc_no_dtor if no finalization
is needed.
(ggc_cleared_vec_alloc): Call ggc_internal_cleared_alloc_no_dtor if no
finalization is needed.
* ggc-page.cc (ggc_internal_alloc): If HAVE_ATTRIBUTE_ALIAS, turn
overload with finalizer into alias to ggc_internal_alloc_ and
rename it to ...
(ggc_internal_alloc_): ... this, make it extern "C".
(ggc_internal_alloc_no_dtor): New alias if HAVE_ATTRIBUTE_ALIAS,
otherwise new noinline wrapper.
* ggc-common.cc (ggc_internal_cleared_alloc): If HAVE_ATTRIBUTE_ALIAS,
turn overload with finalizer into alias to ggc_internal_alloc_ and
rename it to ...
(ggc_internal_cleared_alloc_): ... this, make it extern "C".
(ggc_internal_cleared_alloc_no_dtor): New alias if
HAVE_ATTRIBUTE_ALIAS, otherwise new noinline wrapper.
* ggc-none.cc (ggc_internal_alloc): If HAVE_ATTRIBUTE_ALIAS, turn
overload with finalizer into alias to ggc_internal_alloc_ and
rename it to ...
(ggc_internal_alloc_): ... this, make it extern "C".
(ggc_internal_alloc_no_dtor): New alias if HAVE_ATTRIBUTE_ALIAS,
otherwise new wrapper.
(ggc_internal_cleared_alloc): If HAVE_ATTRIBUTE_ALIAS, turn overload
with finalizer into alias to ggc_internal_alloc_ and rename it to ...
(ggc_internal_cleared_alloc_): ... this, make it extern "C".
(ggc_internal_cleared_alloc_no_dtor): New alias if
HAVE_ATTRIBUTE_ALIAS, otherwise new wrapper.
* genmatch.cc (ggc_internal_cleared_alloc, ggc_free): Formatting fix.
(ggc_internal_cleared_alloc_no_dtor): Define.
* config.in: Regenerate.
* configure: Regenerate.
Jakub Jelinek [Sat, 1 Mar 2025 08:15:57 +0000 (09:15 +0100)]
openmp: Fix up simd clone mask argument creation on x86 [PR115871]
The following testcase ICEs since r14-5057.
The Intel vector ABI says that in the ZMM case the masks is passed
in unsigned int or unsigned long long arguments and how many bits in
them and how many of those arguments are is determined by the characteristic
data type of the function. In the testcase simdlen is 32 and characteristic
data type is double, so return as well as first argument is passed in 4
V8DFmode arguments and the mask is supposed to be passed in 4 unsigned int
arguments (8 bits in each).
Before the r14-5057 change there was
sc->args[i].orig_type = parm_type;
...
case SIMD_CLONE_ARG_TYPE_LINEAR_VAL_CONSTANT_STEP:
case SIMD_CLONE_ARG_TYPE_LINEAR_VAL_VARIABLE_STEP:
case SIMD_CLONE_ARG_TYPE_VECTOR:
if (INTEGRAL_TYPE_P (parm_type) || POINTER_TYPE_P (parm_type))
veclen = sc->vecsize_int;
else
veclen = sc->vecsize_float;
if (known_eq (veclen, 0U))
veclen = sc->simdlen;
else
veclen
= exact_div (veclen,
GET_MODE_BITSIZE (SCALAR_TYPE_MODE (parm_type)));
for the argument handling and
if (sc->inbranch)
{
tree base_type = simd_clone_compute_base_data_type (sc->origin, sc);
...
if (INTEGRAL_TYPE_P (base_type) || POINTER_TYPE_P (base_type))
veclen = sc->vecsize_int;
else
veclen = sc->vecsize_float;
if (known_eq (veclen, 0U))
veclen = sc->simdlen;
else
veclen = exact_div (veclen,
GET_MODE_BITSIZE (SCALAR_TYPE_MODE (base_type)));
for the mask handling. r14-5057 moved this argument creation later and
unified that:
case SIMD_CLONE_ARG_TYPE_MASK:
case SIMD_CLONE_ARG_TYPE_LINEAR_VAL_CONSTANT_STEP:
case SIMD_CLONE_ARG_TYPE_LINEAR_VAL_VARIABLE_STEP:
case SIMD_CLONE_ARG_TYPE_VECTOR:
if (sc->args[i].arg_type == SIMD_CLONE_ARG_TYPE_MASK
&& sc->mask_mode != VOIDmode)
elem_type = boolean_type_node;
else
elem_type = TREE_TYPE (sc->args[i].vector_type);
if (INTEGRAL_TYPE_P (elem_type) || POINTER_TYPE_P (elem_type))
veclen = sc->vecsize_int;
else
veclen = sc->vecsize_float;
if (known_eq (veclen, 0U))
veclen = sc->simdlen;
else
veclen
= exact_div (veclen,
GET_MODE_BITSIZE (SCALAR_TYPE_MODE (elem_type)));
This is correct for the argument cases (so linear or vector) (though
POINTER_TYPE_P will never appear as TREE_TYPE of a vector), but the
boolean_type_node in there is completely bogus, when using AVX512 integer
masks as I wrote above we need the characteristic data type, not bool,
and bool is strange in that it has bitsize of 8 (or 32 on darwin), while
the masks are 1 bit per lane anyway.
Fixed thusly.
2025-03-01 Jakub Jelinek <jakub@redhat.com>
PR middle-end/115871
* omp-simd-clone.cc (simd_clone_adjust): For SIMD_CLONE_ARG_TYPE_MASK
and sc->mask_mode not VOIDmode, set elem_type to the characteristic
type rather than boolean_type_node.
Jan Dubiec [Sat, 1 Mar 2025 05:01:42 +0000 (22:01 -0700)]
[PATCH] H8/300: PR target/109189 Silence -Wformat warnings on Windows
This patch fixes annoying -Wformat warnings when gcc is built
on Windows/MinGW64. Instead of %ld it uses HOST_WIDE_INT_PRINT_DEC
macro, just like many other targets do.
PR target/109189
gcc/ChangeLog:
* config/h8300/h8300.cc (h8300_print_operand): Replace %ld format
strings with HOST_WIDE_INT_PRINT_DEC macro in order to silence
-Wformat warnings when building on Windows/MinGW64.
Jonathan Wakely [Fri, 28 Feb 2025 21:44:41 +0000 (21:44 +0000)]
libstdc++: Fix ranges::iter_move handling of rvalues [PR106612]
The specification for std::ranges::iter_move apparently requires us to
handle types which do not satisfy std::indirectly_readable, for example
with overloaded operator* which behaves differently for different value
categories.
libstdc++-v3/ChangeLog:
PR libstdc++/106612
* include/bits/iterator_concepts.h (_IterMove::__iter_ref_t):
New alias template.
(_IterMove::__result): Use __iter_ref_t instead of
std::iter_reference_t.
(_IterMove::__type): Remove incorrect __dereferenceable
constraint.
(_IterMove::operator()): Likewise. Add correct constraints. Use
__iter_ref_t instead of std::iter_reference_t. Forward parameter
as correct value category.
(iter_swap): Add comments.
* testsuite/24_iterators/customization_points/iter_move.cc: Test
that iter_move is found by ADL and that rvalue arguments are
handled correctly.
Jonathan Wakely [Thu, 27 Feb 2025 13:27:17 +0000 (13:27 +0000)]
libstdc++: Fix ranges::move and ranges::move_backward to use iter_move [PR105609]
The ranges::move and ranges::move_backward algorithms are supposed to
use ranges::iter_move(iter) instead of std::move(*iter), which matters
for an iterator type with an iter_move overload findable by ADL.
Currently those algorithms use std::__assign_one which uses std::move,
so define a new ranges::__detail::__assign_one helper function that uses
ranges::iter_move.
libstdc++-v3/ChangeLog:
PR libstdc++/105609
* include/bits/ranges_algobase.h (__detail::__assign_one): New
helper function.
(__copy_or_move, __copy_or_move_backward): Use new function
instead of std::__assign_one.
* testsuite/25_algorithms/move/constrained.cc: Check that
ADL iter_move is used in preference to std::move.
* testsuite/25_algorithms/move_backward/constrained.cc:
Likewise.
Jonathan Wakely [Thu, 27 Feb 2025 15:48:49 +0000 (15:48 +0000)]
libstdc++: Add static_assertions to ranges::to adaptor factory [PR112803]
The standard requires that we reject attempts to create a ranges::to
adaptor for cv-qualified types and non-class types. Currently we only
diagnose it once the adaptor is used in a pipeline.
This adds static assertions to diagnose it immediately.
libstdc++-v3/ChangeLog:
PR libstdc++/112803
* include/std/ranges (ranges::to): Add static assertions to
enforce Mandates conditions.
* testsuite/std/ranges/conv/112803.cc: 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.
The initial &<retval>._M_local_buf was not constant, but since
HelloWorld is a static VAR_DECL, the resulting &HelloWorld._M_local_buf
should have been marked as TREE_CONSTANT. And since we're taking
its address, the whole thing should be TREE_ADDRESSABLE.
PR c++/114913
PR c++/110822
gcc/cp/ChangeLog:
* constexpr.cc (replace_decl_r): If we've replaced something
inside of an ADDR_EXPR, call cxx_mark_addressable and
recompute_tree_invariant_for_addr_expr on the resulting ADDR_EXPR.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/constexpr-nsdmi4.C: New test.
* g++.dg/cpp0x/constexpr-nsdmi5.C: New test.
so when we call maybe_constant_init, the object we're initializing is D.2701,
and the init is the expr_stmt. We unwrap the EXPR_STMT/INIT_EXPR/TARGET_EXPR
in maybe_constant_init_1 and so end up evaluating the f1 call. But f1 returns
c2 whereas the type of D.2701 is ._anon_0 -- the closure.
cxx_eval_outermost_constant_expr is already ready for the types to be
different, in which case the result isn't constant. But replace_decl
is called before that check.
I'm leaving the assert in replace_decl on purpose, maybe we'll find
another use for it.
PR c++/118986
gcc/cp/ChangeLog:
* constexpr.cc (cxx_eval_call_expression): Check that the types match
before calling replace_decl, if not, set *non_constant_p.
(maybe_constant_init_1): Don't strip INIT_EXPR if it would change the
type of the expression.
Martin Jambor [Fri, 28 Feb 2025 16:34:10 +0000 (17:34 +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.
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.
It turns out the reason the behavior of this testcase changed after CWG
2369 is because validity of the substituted return type is now checked
later, after constraints. So a more reliable workaround for this issue
is to add a constraint to check the validity of the return type earlier,
matching the pre-CWG 2369 semantics.
PR libstdc++/104606
libstdc++-v3/ChangeLog:
* include/std/optional (operator<=>): Revert r14-9771 change.
Add constraint checking the validity of the return type
compare_three_way_result_t before the three_way_comparable_with
constraint.
Patrick Palka [Fri, 28 Feb 2025 14:39:57 +0000 (09:39 -0500)]
libstdc++: Fix constraint recursion in basic_const_iterator relops [PR112490]
Here for
using RCI = reverse_iterator<basic_const_iterator<vector<int>::iterator>>
static_assert(std::totally_ordered<RCI>);
we effectively need to check the requirement
requires (RCI x) { x RELOP x; } for each RELOP in {<, >, <=, >=}
which we expect to be straightforwardly satisfied by reverse_iterator's
namespace-scope relops. But due to ADL we find ourselves also
considering the basic_const_iterator relop friends, which before CWG
2369 would be quickly discarded since RCI clearly isn't convertible to
basic_const_iterator. After CWG 2369 though we must first check these
relops' constraints (with _It = vector<int>::iterator and _It2 = RCI),
which entails checking totally_ordered<RCI> recursively.
This patch fixes this by turning the problematic non-dependent function
parameters of type basic_const_iterator<_It> into dependent ones of
type basic_const_iterator<_It3> where _It3 is constrained to match _It.
Thus the basic_const_iterator relop friends now get quickly discarded
during deduction and before the constraint check if the second operand
isn't a specialization of basic_const_iterator (or derived from one)
like before CWG 2369.
PR libstdc++/112490
libstdc++-v3/ChangeLog:
* include/bits/stl_iterator.h (basic_const_iterator::operator<):
Replace non-dependent basic_const_iterator function parameter with
a dependent one of type basic_const_iterator<_It3> where _It3
matches _It.
(basic_const_iterator::operator>): Likewise.
(basic_const_iterator::operator<=): Likewise.
(basic_const_iterator::operator>=): Likewise.
* testsuite/24_iterators/const_iterator/112490.cc: New test.
projects / thirdparty / gcc.git / log
