Tomasz Kamiński [Thu, 24 Apr 2025 14:03:27 +0000 (16:03 +0200)]
libstdc++: Cleanup and stabilize format _Spec<_CharT> and _Pres_type.
These patch makes following changes to _Pres_type values:
* _Pres_esc is replaced with separate _M_debug flag.
* _Pres_s, _Pres_p do not overlap with _Pres_none.
* hexadecimal presentation use same values for pointer, integer
and floating point types.
The members of _Spec<_CharT> are rearranged so the class contains 8 bits
reserved for future use (_M_reserved) and 8 bits of tail padding.
Derived classes (like _ChronoSpec<_CharT>) can reuse the storage for initial
members. We also add _SpecBase as the base class for _Spec<_CharT> to make
it non-C++98 POD, which allows tail padding to be reused on Itanium ABI.
Finally, the format enumerators are defined as enum class with unsigned
char as underlying type, followed by using enum to bring names in scope.
_Term_char names are adjusted for consistency, and enumerator values are
changed so it can fit in smaller bitfields.
The '?' is changed to separate _M_debug flag, to allow debug format to be
independent from the presentation type, and applied to multiple presentation
types. For example it could be used to trigger memberwise or reflection based
formatting.
The _M_format_character and _M_format_character_escaped functions are merged
to single function that handle normal and debug presentation. In particular
this would allow future support for '?c' for printing integer types as escaped
character. _S_character_width is also folded in the merged function.
Decoupling _Pres_s value from _Pres_none, allows it to be used for string
presentation for range formatting, and removes the need for separate _Pres_seq
and _Pres_str. This does not affect formatting of bool as __formatter_int::_M_parse
overrides default value of _M_type. And with separation of the _M_debug flag,
__formatter_str::format behavior is now agnostic to _M_type value.
The values for integer presentation types, are arranged so textual presentations
(_Prec_s, _Pres_c) are grouped together. For consistency floating point
hexadecimal presentation uses the same values as integer ones.
New _Pres_p and setting for _M_alt enables using some spec to configure formatting
of uintptr_t with __formatter_int, and const void* with __formatter_ptr.
Differentiating it from _Pres_none would allow future of formatter<T*, _CharT>
that would require explicit presentation type to be specified. This would allow
std::vector<T*> to be formatted directly with '{::p}' format spec.
The constructors for __formatter_int and _formatter_ptr from _Spec<_CharT>,
now also set default presentation modes, as format functions expects them.
libstdc++-v3/ChangeLog:
* include/bits/chrono_io.h (_ChronoSpec::_M_locale_specific):
Declare as bit fiekd in tail-padding..
* include/bits/formatfwd.h (__format::_Align): Defined as enum
class and add using enum.
* include/std/format (__format::_Pres_type, __format::_Sign)
(__format::_WidthPrec, __format::_Arg_t): Defined as enum class
and add using enum.
(_Pres_type::_Pres_esc): Replace with _Pres_max.
(_Pres_type::_Pres_seq, _Pres_type::_Pres_str): Remove.
(__format::_Pres_type): Updated values of enumerators as described
above.
(__format::_Spec): Rearranged members to have 8 bits of tail-padding.
(_Spec::_M_debug): Defined.
(_Spec::_M_reserved): Extended to 8 bits and moved at the end.
(_Spec::_M_reserved2): Removed.
(_Spec::_M_parse_fill_and_align, _Spec::_M_parse_sign)
(__format::__write_padded_as_spec): Adjusted default value checks.
(__format::_Term_char): Add using enum and adjust enumertors.
(__Escapes::_S_term): Adjusted for _Term_char values.
(__format::__should_escape_ascii): Adjusted _Term_char uses.
(__format::__write_escaped): Adjusted for _Term_char.
(__formatter_str::parse): Set _Pres_s if specifed and _M_debug
instead of _Pres_esc.
(__formatter_str::set_debug_format): Set _M_debug instead of
_Pres_esc.
(__formatter_str::format, __formatter_str::_M_format_range):
Check _M_debug instead of _Prec_esc.
(__formatter_str::_M_format_escaped): Adjusted _Term_char uses.
(__formatter_int::__formatter_int(_Spec<_CharT>)): Set _Pres_d if
default presentation type is not set.
(__formatter_int::_M_parse): Adjusted default value checks.
(__formatter_int::_M_do_parse): Set _M_debug instead of _Pres_esc.
(__formatter_int::_M_format_character): Handle escaped presentation.
(__formatter_int::_M_format_character_escaped)
(__formatter_int::_S_character_width): Merged into
_M_format_character.
(__formatter_ptr::__formatter_ptr(_Spec<_CharT>)): Set _Pres_p if
default presentation type is not set.
(__formatter_ptr::parse): Add default __type parameter, store _Pres_p,
and handle _M_alt to be consistent with meaning for integers.
(__foramtter_ptr<_CharT>::_M_set_default): Define.
(__format::__pack_arg_types, std::basic_format_args): Add necessary
casts.
(formatter<_CharT, _CharT>::set_debug_format)
(formatter<char, wchar_t>::set_debug_format): Set _M_debug instead of
_Pres_esc.
(formatter<_CharT, _CharT>::format, formatter<char, wchar_t>::format):
Simplify calls to _M_format_character.
(range_formatter<_Rg, _CharT>::parse): Replace _Pres_str with
_Pres_s and set _M_debug instead of _Pres_esc.
(range_formatter<_Rg, _CharT>::format): Replace _Pres_str with
_Pres_s.
Reviewed-by: Jonathan Wakely <jwakely@redhat.com> Signed-off-by: Tomasz Kamiński <tkaminsk@redhat.com>
Jonathan Wakely [Tue, 20 May 2025 09:53:41 +0000 (10:53 +0100)]
libstdc++: Fix incorrect links to archived SGI STL docs
In r8-7777-g25949ee33201f2 I updated some URLs to point to copies of the
SGI STL docs in the Wayback Machine, because the original pags were no
longer hosted on sgi.com. However, I incorrectly assumed that if one
archived page was at https://web.archive.org/web/20171225062613/... then
all the other pages would be too. Apparently that's not how the Wayback
Machine works, and each page is archived on a different date. That meant
that some of our links were redirecting to archived copies of the
announcement that the SGI STL docs have gone away.
This fixes each URL to refer to a correctly archived copy of the
original docs.
Jakub Jelinek [Tue, 20 May 2025 07:36:58 +0000 (09:36 +0200)]
libgcc: Move bitint support exports to x86/aarch64 specific map files
When adding _BitInt support I was hoping all or most of arches would
implement it already for GCC 14. That didn't happen and with
new hosts adding support for _BitInt for GCC 16 (s390x-linux and as was
posted today loongarch-linux too), we need the _BitInt support functions
exported on those arches at GCC_16.0.0 rather than GCC_14.0.0 which
shouldn't be changed anymore.
The following patch does that. Both arches were already exporting
some of the _BitInt related symbols in their specific map files, this
just moves the remaining ones there as well.
2025-05-20 Jakub Jelinek <jakub@redhat.com>
* libgcc-std.ver.in (GCC_14.0.0): Remove bitint related exports
from here.
* config/i386/libgcc-glibc.ver (GCC_14.0.0): Add them here.
* config/i386/libgcc-darwin.ver (GCC_14.0.0): Likewise.
* config/i386/libgcc-sol2.ver (GCC_14.0.0): Likewise.
* config/aarch64/libgcc-softfp.ver (GCC_14.0.0): Likewise.
Jakub Jelinek [Tue, 20 May 2025 06:21:14 +0000 (08:21 +0200)]
tree-chrec: Use signed_type_for in convert_affine_scev
On s390x-linux I've run into the gcc.dg/torture/bitint-27.c test ICEing in
build_nonstandard_integer_type called from convert_affine_scev (not sure
why it doesn't trigger on x86_64/aarch64).
The problem is clear, when ct is a BITINT_TYPE with some large
TYPE_PRECISION, build_nonstandard_integer_type won't really work on it.
The patch fixes it similarly what has been done for GCC 14 in various
other spots.
2025-05-20 Jakub Jelinek <jakub@redhat.com>
* tree-chrec.cc (convert_affine_scev): Use signed_type_for instead of
build_nonstandard_integer_type.
Jakub Jelinek [Tue, 20 May 2025 06:20:16 +0000 (08:20 +0200)]
libgcc: Small bitint_reduce_prec big-endian fixes
The big-endian _BitInt support in libgcc was written without any
testing and so I haven't discovered I've made one mistake in it
(in multiple places).
The bitint_reduce_prec function attempts to optimize inputs
which have some larger precision but at runtime they are found
to need smaller number of limbs.
For little-endian that is handled just by returning smaller
precision (or negative precision for signed), but for
big-endian we need to adjust the passed in limb pointer so that
when it returns smaller precision the argument still contains
the least significant limbs for the returned precision.
2025-05-20 Jakub Jelinek <jakub@redhat.com>
* libgcc2.c (bitint_reduce_prec): For big endian
__LIBGCC_BITINT_ORDER__ use ++*p and --*p instead of
++p and --p.
* soft-fp/bitint.h (bitint_reduce_prec): Likewise.
Jakub Jelinek [Tue, 20 May 2025 06:18:58 +0000 (08:18 +0200)]
bitintlower: Big-endian lowering support
The following patch adds big endian support to the bitintlower pass.
While the rest of the _BitInt support has been written with endianity
in mind, in the bitintlower pass I've written it solely little endian
at the start, because the pass is large and complicated and there were
no big-endian backends with _BitInt psABI at the point of writing it,
so the big-endian support would be completely untested.
Now that I got privately a patch to add s390x support, I went through
the whole pass and added the support.
Some months ago I've talked about two possibilities to do the big-endian
support, one perhaps easier would be keep the idx vars (INTEGER_CSTs
for bitint_prec_large and partially SSA_NAMEs, partially INTEGER_CSTs
for bitint_prec_huge) iterating like for little-endian from 0 upwards
and do the big-endian index correction only when accessing the limbs
(but mergeable casts between _BitInts with different number of limbs
would be a nightmare), which would have the disadvantage that we'd need
to wait until propagation and ivopts to fix stuff up (and not sure it
would be able to fix everything), or change stuff so that the idxes
used between the different bitint_large_huge class methods iterate on
big endian from highest down to 0.
The following patch implements the latter.
On s390x with the 3 patches from IBM without this patch I got on
make -j32 -k check-gcc GCC_TEST_RUN_EXPENSIVE=1 RUNTESTFLAGS="GCC_TEST_RUN_EXPENSIVE=1 dg.exp='*bitint* pr112673.c builtin-stdc-bit-*.c pr112566-2.c pr112511.c pr116588.c pr116003.c
+pr113693.c pr113602.c flex-array-counted-by-7.c' dg-torture.exp='*bitint* pr116480-2.c pr114312.c pr114121.c' dfp.exp=*bitint* vect.exp='vect-early-break_99-pr113287.c'
+tree-ssa.exp=pr113735.c"
347 FAILs, 326 out of that execution failures (and that doesn't include
some tests that happened to succeed by pure luck because e.g. comparisons
weren't implemented correctly).
With this patch (and 2 small patches I'm going to post next) I got this
down to
FAIL: gcc.dg/dfp/bitint-1.c (test for excess errors)
FAIL: gcc.dg/dfp/bitint-2.c (test for excess errors)
FAIL: gcc.dg/dfp/bitint-3.c (test for excess errors)
FAIL: gcc.dg/dfp/bitint-4.c (test for excess errors)
FAIL: gcc.dg/dfp/bitint-5.c (test for excess errors)
FAIL: gcc.dg/dfp/bitint-6.c (test for excess errors)
FAIL: gcc.dg/dfp/bitint-8.c (test for excess errors)
FAIL: gcc.dg/torture/bitint-64.c -O3 -g execution test
FAIL: gcc.dg/torture/bitint-64.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects execution test
where the dfp stuff is due to missing DPD dfp <-> _BitInt support
I'm working on next, and bitint-64.c is some expansion related
issue with _Atomic _BitInt(5) (will look at it later, but there
bitint lowering isn't involved at all).
Most of the patch just tweaks things so that it iterates in the
right direction, for casts with different number of limbs does the
needed index adjustments and unfortunately due to that (and e.g.
add/sub/mul overflow BE lowering) has some pessimizations on the
SSA conflict side; on little-endian mergeable ops have the
advantage that all the accesses iterate from index 0 up, so even
if there is e.g. overlap between the lhs and some used values, except
for mul/div where libgcc APIs require no overlap we don't need to
avoid it, all the limbs are updated in sync before going on to handle
next limb. On big-endian, that isn't the case, casts etc. can result
in index adjustments and so we could overwrite a limb that will still
need to be processed as input. So, there is a special case that looks
for different numbers of limbs among arguments and in that case marks
the lhs as conflicting with the inputs.
On little-endian, this patch shouldn't affect code generation, with
one little exception; in the separate_ext handling in lower_mergeable_stmt
the loop (if bitint_large_huge) was iterating using some idx and then
if bo_idx was non-zero, adding that constant to a new SSA_NAME and using
that to do the limb accesses. As the limb accesses are the only place
where the idx is used (apart from the loop exit test), I've changed it
to iterate on idxes with bo_idx already added to those.
P.S., would be nice to eventually also enable big-endian aarch64,
but I don't have access to those, so can't test that myself.
P.S., at least in the current s390x patches it wants info->extended_p,
this patch doesn't change anything about that. I believe most of the
time the _BitInt vars/params/return values are already extended, but
there is no testcase coverage for that, I will work on that incrementally
(and then perhaps arm 32-bit _BitInt support can be enabled too).
* gcc.dg/torture/bitint-78.c: New test.
* gcc.dg/torture/bitint-79.c: New test.
* gcc.dg/torture/bitint-80.c: New test.
* gcc.dg/torture/bitint-81.c: New test.
Nathaniel Shead [Mon, 19 May 2025 12:11:13 +0000 (22:11 +1000)]
c++/modules: Ensure vtables are emitted when needed [PR120349]
I missed a testcase in r16-688-gc875748cdc468e for whether a GM vtable
should be emitted in an importer when it has no non-inline key function.
Before that patch the code worked because always we marked all vtables
as DECL_EXTERNAL, which then meant that reading the definition marked
them as DECL_NOT_REALLY_EXTERN.
This patch restores the old behaviour so that vtables are marked
DECL_EXTERNAL (and hence DECL_NOT_REALLY_EXTERN).
PR c++/120349
gcc/cp/ChangeLog:
* module.cc (trees_out::core_bools): Always mark vtables as
DECL_EXTERNAL.
gcc/testsuite/ChangeLog:
* g++.dg/modules/vtt-3_a.C: New test.
* g++.dg/modules/vtt-3_b.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com> Reviewed-by: Jason Merrill <jason@redhat.com>
Jeff Law [Tue, 20 May 2025 02:31:27 +0000 (20:31 -0600)]
[RISC-V] Avoid multiple assignments to output object
This is the next batch of changes to reduce multiple assignments to an output
object. This time I'm focused on splitters in bitmanip.md.
This doesn't convert every case. For example there is one case that is very
clearly dependent on eliminating mvconst_internal and adjustment of a splitter
for andn and until those things happen it would clearly be a QOI implementation
regression.
There are cases where we set a scratch register more than once. It may be
possible to use an additional scratch. I haven't tried that yet.
I've seen one failure to if-convert a sequence after this patch, but it should
be resolved once the logical AND changes are merged. Otherwise I'm primarily
seeing slight differences in register allocation and scheduling. Nothing
concerning to me.
This has run through my tester, but I obviously want to see how it behaves in
the upstream CI system as that tests slightly different multilibs than mine (on
purpose).
gcc/
* config/riscv/bitmanip.md (various splits): Avoid writing the output
more than once when trivially possible.
Nathaniel Shead [Sat, 17 May 2025 13:51:07 +0000 (23:51 +1000)]
c++/modules: Fix ICE on merge of instantiation with partial spec [PR120013]
When we import a pending instantiation that matches an existing partial
specialisation, we don't find the slot in the entity map because for
partial specialisations we register the TEMPLATE_DECL but for normal
implicit instantiations we instead register the inner TYPE_DECL.
Because the DECL_MODULE_ENTITY_P flag is set we correctly realise that
it is in the entity map, but ICE when attempting to use that slot in
partition handling.
This patch fixes the issue by detecting this case and instead looking
for the slot for the TEMPLATE_DECL. It doesn't matter that we never add
a slot for the inner decl because we're about to discard it anyway.
PR c++/120013
gcc/cp/ChangeLog:
* module.cc (trees_in::install_entity): Handle re-registering
the inner TYPE_DECL of a partial specialisation.
gcc/testsuite/ChangeLog:
* g++.dg/modules/partial-8.h: New test.
* g++.dg/modules/partial-8_a.C: New test.
* g++.dg/modules/partial-8_b.C: New test.
* g++.dg/modules/partial-8_c.C: New test.
* g++.dg/modules/partial-8_d.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com> Reviewed-by: Jason Merrill <jason@redhat.com>
Nathaniel Shead [Mon, 19 May 2025 13:17:16 +0000 (23:17 +1000)]
c++/modules: Always mark tinfo vars as TREE_ADDRESSABLE [PR120350]
We need to mark type info decls as addressable if we take them by
reference; this is done by walking the declaration during parsing and
marking the decl as needed.
However, with modules we don't stream tinfo decls directly; rather we
stream just their name and type and reconstruct them in the importer
directly. This means that any addressable flags are not propagated, and
we error because TREE_ADDRESSABLE is not set despite taking its address.
But tinfo decls should always have TREE_ADDRESSABLE set, as any attempt
to use the tinfo decl will go through build_address anyway. So this
patch fixes the issue by eagerly marking the constructed decl as
TREE_ADDRESSABLE so that modules gets this flag correctly set as well.
PR c++/120350
gcc/cp/ChangeLog:
* rtti.cc (get_tinfo_decl_direct): Mark TREE_ADDRESSABLE.
gcc/testsuite/ChangeLog:
* g++.dg/modules/tinfo-3_a.H: New test.
* g++.dg/modules/tinfo-3_b.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com> Reviewed-by: Jason Merrill <jason@redhat.com>
Pan Li [Sun, 18 May 2025 08:41:01 +0000 (16:41 +0800)]
RISC-V: Combine vec_duplicate + vrsub.vv to vrsub.vx on GR2VR cost
This patch would like to combine the vec_duplicate + vrub.vv to the
vrsub.vx. From example as below code. The related pattern will depend
on the cost of vec_duplicate from GR2VR. Then the late-combine will
take action if the cost of GR2VR is zero, and reject the combination
if the GR2VR cost is greater than zero.
Assume we have example code like below, GR2VR cost is 0.
#define DEF_VX_BINARY_REVERSE_CASE_0(T, OP, NAME) \
void \
test_vx_binary_reverse_##NAME##_##T##_case_0 (T * restrict out, \
T * restrict in, T x, \
unsigned n) \
{ \
for (unsigned i = 0; i < n; i++) \
out[i] = x OP in[i]; \
}
The below test suites are passed for this patch.
* The rv64gcv fully regression test.
gcc/ChangeLog:
* config/riscv/autovec-opt.md: Leverage the new add func to
expand the vx insn.
* config/riscv/riscv-protos.h (expand_vx_binary_vec_dup_vec): Add
new func decl to expand format v = vop(vec_dup(x), v).
(expand_vx_binary_vec_vec_dup): Diito but for format
v = vop(v, vec_dup(x)).
* config/riscv/riscv-v.cc (expand_vx_binary_vec_dup_vec): Add new
func impl to expand vx for v = vop(vec_dup(x), v).
(expand_vx_binary_vec_vec_dup): Diito but for another format
v = vop(v, vec_dup(x)).
I goof'd when doing analysis of missed bext cases. For the shift into the sign
bit, then shift into the low bit case (thankfully the least common), I got it
in my brain that the field is at the left shift count. It's actually at
word_size - 1 - left shift count.
One the subtraction is included, it's no longer profitable to turn those cases
into bext. Best case scenario would be sub+bext, but we can just as easily use
sll+srl which fuses in some designs into a single op.
So this patch removes those two patterns, adjusts the existing testcase and
adds the new execution test.
Given it's a partial reversion and has passed in my tester, I'm going to go
ahead and push it to the trunk rather than waiting for upstream CI.
PR target/120333
gcc/
* config/riscv/bitmanip.md: Remove bext formed from left+right
shift patterns.
gcc/testsuite/
* gcc.target/riscv/pr114512.c: Update expected output.
* gcc.target/riscv/pr120333.c: New test.
hpux: Fix detection of atomic support when profiling
The pa target lacks atomic sync compare and swap instructions.
These are implemented as libcalls and in libatomic. As on linux,
we lie about their availability.
This fixes the gcov-30.c test on hppa64-hpux11.
2025-05-19 John David Anglin <danglin@gcc.gnu.org>
/* Handle empty records as per the x86-64 psABI. */
TYPE_EMPTY_P (type) = targetm.calls.empty_record_p (type);
(Indeed x86_64 is still the only target to define 'TARGET_EMPTY_RECORD_P',
calling 'gcc/tree.cc-default_is_empty_record'.)
And so it happens that for an empty struct used in code offloaded from x86_64
host (but not powerpc64le host, for example), we get to see 'TYPE_EMPTY_P' in
offloading compilation (where the offload targets (currently?) don't use it
themselves, and therefore aren't prepared to handle it).
For nvptx offloading compilation, this causes wrong code generation:
'ptxas [...] error : Call has wrong number of parameters', as nvptx code
generation for function definition doesn't pay attention to this flag (say, in
'gcc/config/nvptx/nvptx.cc:pass_in_memory', or whereever else would be
appropriate to handle that), but the generic code 'gcc/calls.cc:expand_call'
via 'gcc/function.cc:aggregate_value_p' does pay attention to it, and we thus
get mismatching function definition vs. function call.
This issue apparently isn't a problem for GCN offloading, but I don't know if
that's by design or by accident.
Richard Biener:
> It looks like TYPE_EMPTY_P is only used during RTL expansion for ABI
> purposes, so computing it during layout_type is premature as shown here.
>
> I would suggest to simply re-compute it at offload stream-in time.
(For avoidance of doubt, the additions to 'gcc.target/nvptx/abi-struct-arg.c',
'gcc.target/nvptx/abi-struct-ret.c' are not dependent on the offload streaming
code changes, but are just to mirror the changes to
'libgomp.oacc-c-c++-common/abi-struct-1.c'.)
Jeff Law [Mon, 19 May 2025 18:00:56 +0000 (12:00 -0600)]
[RISC-V] Fix false positive from Wuninitialized
As Mark and I independently tripped, there's a Wuninitialized issue in the
RISC-V backend. While *I* know the value would always be properly initialized,
it'd be somewhat painful to either eliminate the infeasible paths or do deep
enough analysis to suppress the false positive.
So this initializes OUTPUT and verifies it's got a reasonable value before
using it for the final copy into operands[0].
Bootstrapped on the BPI (regression testing still has ~12hrs to go).
gcc/
* config/riscv/riscv.cc (synthesize_ior_xor): Initialize OUTPUT and
verify it's non-null before emitting the final copy insn.
Harald Anlauf [Sun, 18 May 2025 20:42:26 +0000 (22:42 +0200)]
Fortran: fix FAIL of gfortran.dg/specifics_1.f90 after r16-372 [PR120099]
After commit r16-372, testcase gfortran.dg/specifics_1.f90 started to
FAIL at -O2 and higher, as DCE lead to elimination of evaluations of
Fortran specific intrinsics returning complex results and with -ff2c.
As the Fortran runtime library is compiled with -fno-f2c, the frontend
generates calls to wrapper subroutines _gfortran_f2c_specific_* that
return their result by reference via their first argument when this is
needed. This is e.g. the case when specific names of the intrinsics are
used for passing as actual argument to procedures. These wrappers are
not pure in the GCC IR sense, even if the Fortran intrinsics are.
Therefore gfc_return_by_reference must return true for these.
PR fortran/120099
gcc/fortran/ChangeLog:
* trans-types.cc (gfc_return_by_reference): Intrinsic functions
returning complex numbers may return their result by reference
with -ff2c.
Richard Earnshaw [Mon, 19 May 2025 15:19:39 +0000 (16:19 +0100)]
arm: fully validate mem_noofs_operand [PR120351]
It's not enough to just check that a memory operand is of the form
mem(reg); after RA we also need to validate the register being used.
The safest way to do this is to call memory_operand.
PR target/120351
gcc/ChangeLog:
* config/arm/predicates.md (mem_noofs_operand): Also check the op
is a valid memory_operand.
Jonathan Wakely [Fri, 16 May 2025 10:54:46 +0000 (11:54 +0100)]
libstdc++: Fix some Clang -Wsystem-headers warnings in <ranges>
libstdc++-v3/ChangeLog:
* include/std/ranges (_ZipTransform::operator()): Remove name of
unused parameter.
(chunk_view::_Iterator, stride_view::_Iterator): Likewise.
(join_with_view): Declare _Iterator and _Sentinel as class
instead of struct.
(repeat_view): Declare _Iterator as class instead of struct.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
Jonathan Wakely [Thu, 15 May 2025 18:32:01 +0000 (19:32 +0100)]
libstdc++: Fix std::format of chrono::local_days with {} [PR120293]
Formatting of chrono::local_days with an empty chrono-specs should be
equivalent to inserting it into an ostream, which should use the
overload for inserting chrono::sys_days into an ostream. The
implementation of empty chrono-specs in _M_format_to_ostream takes some
short cuts, and that wasn't being done correctly for chrono::local_days.
libstdc++-v3/ChangeLog:
PR libstdc++/120293
* include/bits/chrono_io.h (_M_format_to_ostream): Add special
case for local_time convertible to local_days.
* testsuite/std/time/clock/local/io.cc: Check formatting of
chrono::local_days.
Reviewed-by: Tomasz Kamiński <tkaminsk@redhat.com>
Dongyan Chen [Mon, 19 May 2025 07:17:12 +0000 (15:17 +0800)]
RISC-V: Fix the warning of temporary object dangling references.
During the GCC compilation, some warnings about temporary object dangling
references emerged. They appeared in these code lines in riscv-common.cc:
const riscv_ext_info_t &implied_ext_info, const riscv_ext_info_t &ext_info = get_riscv_ext_info (ext) and auto &ext_info = get_riscv_ext_info (search_ext).
The issue arose because the local variable types were not used in a standardized
way, causing their references to dangle once the function ended.
To fix this, the patch changes the argument type of get_riscv_ext_info to
`const char *`, thereby eliminating the warnings.
Changes for v2:
- Change the argument type of get_riscv_ext_info to `const char *` to eliminate the warnings.
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc (get_riscv_ext_info): Fix argument type.
(riscv_subset_list::check_implied_ext): Type conversion.
zhusonghe [Mon, 19 May 2025 02:43:48 +0000 (10:43 +0800)]
RISC-V: Rename conflicting variables in gen-riscv-ext-texi.cc
The variables `major` and `minor` in `gen-riscv-ext-texi.cc`
conflict with the macros of the same name defined in `<sys/sysmacros.h>`,
which are exposed when building with newer versions of GCC on older
Linux distributions (e.g., Ubuntu 18.04). To resolve this, we rename them
to `major_version` and `minor_version` respectively. This aligns with the
GCC community's recommended practice [1] and improves code clarity.
Kito Cheng [Mon, 12 May 2025 09:38:39 +0000 (02:38 -0700)]
RISC-V: Support Zilsd code gen
This commit adds the code gen support for Zilsd, which is a
newly added extension for RISC-V. The Zilsd extension allows
for loading and storing 64-bit values using even-odd register
pairs.
We only try to do miminal code gen support for that, which means only
use the new instructions when the load store is 64 bits data, we can use
that to optimize the code gen of memcpy/memset/memmove and also the
prologue and epilogue of functions, but I think that probably should be
done in a follow up patch.
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_legitimize_move): Handle
load/store with odd-even reg pair.
(riscv_split_64bit_move_p): Don't split load/store if zilsd enabled.
(riscv_hard_regno_mode_ok): Only allow even reg can be used for
64 bits mode for zilsd.
Jennifer Schmitz [Thu, 15 May 2025 14:16:15 +0000 (07:16 -0700)]
regcprop: Return from copy_value for unordered modes
The ICE in PR120276 resulted from a comparison of VNx4QI and V8QI using
partial_subreg_p in the function copy_value during the RTL pass
regcprop, failing the assertion in
inline bool
partial_subreg_p (machine_mode outermode, machine_mode innermode)
{
/* Modes involved in a subreg must be ordered. In particular, we must
always know at compile time whether the subreg is paradoxical. */
poly_int64 outer_prec = GET_MODE_PRECISION (outermode);
poly_int64 inner_prec = GET_MODE_PRECISION (innermode);
gcc_checking_assert (ordered_p (outer_prec, inner_prec));
return maybe_lt (outer_prec, inner_prec);
}
Returning from the function if the modes are not ordered before reaching
the call to partial_subreg_p resolves the ICE and passes bootstrap and
testing without regression.
OK for mainline?
Signed-off-by: Jennifer Schmitz <jschmitz@nvidia.com>
gcc/
PR middle-end/120276
* regcprop.cc (copy_value): Return in case of unordered modes.
gcc/testsuite/
PR middle-end/120276
* gcc.dg/torture/pr120276.c: New test.
Kito Cheng [Mon, 12 May 2025 06:36:07 +0000 (14:36 +0800)]
RISC-V: Add new operand constraint: cR
This commit introduces a new operand constraint `cR` for the RISC-V
architecture, which allows the use of an even-odd RVC general purpose register
(x8-x15) in inline asm.
Haochen Jiang [Fri, 14 Mar 2025 06:27:36 +0000 (14:27 +0800)]
i386: Remove duplicate iterators in md
There are several iterators no longer needed in md files since
after refactor in AVX10, they could directly use legacy AVX512
ones. Remove those duplicate iterators.
gcc/ChangeLog:
* config/i386/sse.md (VF1_VF2_AVX10_2): Removed.
(VF2_AVX10_2): Ditto.
(VI1248_AVX10_2): Ditto.
(VFH_AVX10_2): Ditto.
(VF1_AVX10_2): Ditto.
(VHF_AVX10_2): Ditto.
(VBF_AVX10_2): Ditto.
(VI8_AVX10_2): Ditto.
(VI2_AVX10_2): Ditto.
(VBF): New.
(div<mode>3): Use VBF instead of AVX10.2 ones.
(vec_cmp<mode><avx512fmaskmodelower>): Ditto.
(avx10_2_cvt2ps2phx_<mode><mask_name><round_name>):
Use VHF_AVX512VL instead of AVX10.2 ones.
(vcvt<convertfp8_pack><mode><mask_name>): Ditto.
(vcvthf82ph<mode><mask_name>): Ditto.
(VHF_AVX10_2_2): Remove not needed TARGET_AVX10_2.
(usdot_prod<sseunpackmodelower><mode>): Use VI2_AVX512F
instead of AVX10.2 ones.
(vdpphps_<mode>): Use VF1_AVX512VL instead of AVX10.2 ones.
(vdpphps_<mode>_mask): Ditto.
(vdpphps_<mode>_maskz): Ditto.
(vdpphps_<mode>_maskz_1): Ditto.
(avx10_2_scalefbf16_<mode><mask_name>): Use VBF instead of
AVX10.2 ones.
(<code><mode>3): Ditto.
(avx10_2_<code>bf16_<mode><mask_name>): Ditto.
(avx10_2_fmaddbf16_<mode>_maskz); Ditto.
(avx10_2_fmaddbf16_<mode><sd_maskz_name>): Ditto.
(avx10_2_fmaddbf16_<mode>_mask): Ditto.
(avx10_2_fmaddbf16_<mode>_mask3): Ditto.
(avx10_2_fnmaddbf16_<mode>_maskz): Ditto.
(avx10_2_fnmaddbf16_<mode><sd_maskz_name>): Ditto.
(avx10_2_fnmaddbf16_<mode>_mask): Ditto.
(avx10_2_fnmaddbf16_<mode>_mask3): Ditto.
(avx10_2_fmsubbf16_<mode>_maskz); Ditto.
(avx10_2_fmsubbf16_<mode><sd_maskz_name>): Ditto.
(avx10_2_fmsubbf16_<mode>_mask): Ditto.
(avx10_2_fmsubbf16_<mode>_mask3): Ditto.
(avx10_2_fnmsubbf16_<mode>_maskz): Ditto.
(avx10_2_fnmsubbf16_<mode><sd_maskz_name>): Ditto.
(avx10_2_fnmsubbf16_<mode>_mask): Ditto.
(avx10_2_fnmsubbf16_<mode>_mask3): Ditto.
(avx10_2_rsqrtbf16_<mode><mask_name>): Ditto.
(avx10_2_sqrtbf16_<mode><mask_name>): Ditto.
(avx10_2_rcpbf16_<mode><mask_name>): Ditto.
(avx10_2_getexpbf16_<mode><mask_name>): Ditto.
(avx10_2_<bf16immop>bf16_<mode><mask_name>): Ditto.
(avx10_2_fpclassbf16_<mode><mask_scalar_merge_name>): Ditto.
(avx10_2_cmpbf16_<mode><mask_scalar_merge_name>): Ditto.
(avx10_2_cvt<sat_cvt_trunc_prefix>bf162i<sat_cvt_sign_prefix>bs<mode><mask_name>):
Ditto.
(avx10_2_cvtph2i<sat_cvt_sign_prefix>bs<mode><mask_name><round_name>):
Use VHF_AVX512VL instead of AVX10.2 ones.
(avx10_2_cvttph2i<sat_cvt_sign_prefix>bs<mode><mask_name><round_saeonly_name>):
Ditto.
(avx10_2_cvtps2i<sat_cvt_sign_prefix>bs<mode><mask_name><round_name>):
Use VF1_AVX512VL instead of AVX10.2 ones.
(avx10_2_cvttps2i<sat_cvt_sign_prefix>bs<mode><mask_name><round_saeonly_name>):
Ditto.
(avx10_2_vcvtt<castmode>2<sat_cvt_sign_prefix>dqs<mode><mask_name><round_saeonly_name>):
Use VF instead of AVX10.2 ones.
(avx10_2_vcvttpd2<sat_cvt_sign_prefix>qqs<mode><mask_name><round_saeonly_name>):
Use VF2 instead of AVX10.2 ones.
(avx10_2_vcvttps2<sat_cvt_sign_prefix>qqs<mode><mask_name><round_saeonly_name>):
Use VI8 instead of AVX10.2 ones.
(avx10_2_minmaxbf16_<mode><mask_name>): Use VBF instead of
AVX10.2 ones.
(avx10_2_minmaxp<mode><mask_name><round_saeonly_name>):
Use VFH_AVX512VL instead of AVX10.2 ones.
(avx10_2_vmovrs<ssemodesuffix><mode><mask_name>):
Use VI1248_AVX512VLBW instead of AVX10.2 ones.
Haochen Jiang [Wed, 14 May 2025 06:57:41 +0000 (14:57 +0800)]
i386: Remove avx10.1-256/512 and evex512 options
As we mentioned in GCC 15, we will remove avx10.1-256/512 and evex512
in GCC 16. Also, the combination of AVX10 and AVX512 option behavior
will also be simplified in GCC 16 since AVX10.1 now implied AVX512,
making the behavior matching everyone else.
Haochen Jiang [Wed, 14 May 2025 07:19:42 +0000 (15:19 +0800)]
i386: Unpush OPTION_MASK_ISA2_EVEX512 for builtins
As we mentioned in GCC 15, we will remove evex512 in GCC 16 since it
is not useful anymore since we will have 512 bit directly. This patch
will first unpush evex512 in the builtins.
emit-rtl: Allow extra checks for paradoxical subregs [PR119966]
When a paradoxical subreg is detected, validate_subreg exits early, thus
skipping the important checks later in the function.
Fix by continuing with the checks instead of declaring early that the
paradoxical subreg is valid.
One of the newly allowed subsequent checks needed to be disabled for
paradoxical subregs. It turned out that combine attempts to create
a paradoxical subreg of mem even for strict-alignment targets.
That is invalid and should eventually be rejected, but is
temporarily left allowed to prevent regressions for
armv8l-unknown-linux-gnueabihf. See PR120329 for more details.
Tests I did:
- No regressions were found for C and C++ for the following targets:
- native x86_64-pc-linux-gnu
- cross riscv64-unknown-linux-gnu
- cross riscv32-none-elf
- Sanity checked armv8l-unknown-linux-gnueabihf by cross-building
up to including libgcc. Linaro CI bot further confirmed there
are no regressions.
- Sanity checked powerpc64-unknown-linux-gnu by building native
toolchain, but I could not setup qemu-user for DejaGnu testing.
PR target/119966
gcc/ChangeLog:
* emit-rtl.cc (validate_subreg): Do not exit immediately for
paradoxical subregs. Filter subsequent tests which are
not valid for paradoxical subregs.
Co-authored-by: Richard Sandiford <richard.sandiford@arm.com> Signed-off-by: Dimitar Dimitrov <dimitar@dinux.eu>
Eric Botcazou [Sun, 18 May 2025 17:10:26 +0000 (19:10 +0200)]
Partially lift restriction from loc_list_from_tree_1
The function accepts all handled_component_p expressions and decodes them by
means of get_inner_reference as expected, but bails out on bitfields:
/* TODO: We can extract value of the small expression via shifting
even for nonzero bitpos. */
if (list_ret == 0)
return 0;
if (!multiple_p (bitpos, BITS_PER_UNIT, &bytepos)
|| !multiple_p (bitsize, BITS_PER_UNIT))
{
expansion_failed (loc, NULL_RTX,
"bitfield access");
return 0;
}
This lifts the second part of the restriction, which helps for obscure cases
of packed discriminated record types in Ada, although this requires the very
latest GDB sources.
gcc/
* dwarf2out.cc (loc_list_from_tree_1) <COMPONENT_REF>: Do not bail
out when the size is not a multiple of a byte.
Deal with bit-fields whose size is not a multiple of a byte when
dereferencing an address.
Andrew Pinski [Sun, 18 May 2025 00:21:39 +0000 (17:21 -0700)]
phiopt: Use mark_lhs_in_seq_for_dce instead of doing it inline
Right now phiopt has the same code as mark_lhs_in_seq_for_dce
inlined into match_simplify_replacement. Instead let's use the
function in gimple-fold that does the same thing.
Bootstrapped and tested on x86_64-linux-gnu.
gcc/ChangeLog:
* gimple-fold.cc (mark_lhs_in_seq_for_dce): Make
non-static.
* gimple-fold.h (mark_lhs_in_seq_for_dce): Declare.
* tree-ssa-phiopt.cc (match_simplify_replacement): Use
mark_lhs_in_seq_for_dce instead of manually looping.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
Oleg Endo [Sat, 17 May 2025 16:51:35 +0000 (10:51 -0600)]
[PATCH] libgcc SH: fix alignment for relaxation
From 6462f1e6a2565c5d4756036d9bc2f39dce9bd768 Mon Sep 17 00:00:00 2001
From: QBos07 <qubos@outlook.de>
Date: Sat, 10 May 2025 16:56:28 +0000
Subject: [PATCH] libgcc SH: fix alignment for relaxation
when relaxation is enabled we can not infer the alignment
from the position as that may change. This should not change
non-relaxed builds as its allready aligned there. This was
the missing piece to building an entire toolchain with -mrelax
Credit goes to Oleg Endo: https://sourceware.org/bugzilla/show_bug.cgi?id=3298#c4
libgcc/
* config/sh/lib1funcs.S (ashiftrt_r4_32): Increase alignment.
(movemem): Force alignment of the mova intruction.
Jeff Law [Sat, 17 May 2025 15:37:01 +0000 (09:37 -0600)]
[RISC-V] Fix ICE due to bogus use of gen_rtvec
Found this while setting up the risc-v coordination branch off of gcc-15. Not
sure why I didn't use rtvec_alloc directly here since we're going to initialize
the whole vector ourselves. Using gen_rtvec was just wrong as it's walking
down a non-existent varargs list. Under the "right" circumstances it can walk
off a page and fault.
This was seen with a test already in the testsuite (I forget which test), so no
new regression test.
Tested in my tester and verified the failure on the coordination branch is
resolved a well. Waiting on pre-commit CI to render a verdict.
gcc/
* config/riscv/riscv-vect-permconst.cc (vector_permconst:process_bb):
Use rtvec_alloc, not gen_rtvec since we don't want/need to initialize
the vector.
Yuao Ma [Sat, 17 May 2025 13:45:49 +0000 (07:45 -0600)]
[PATCH] gcc: add trigonometric pi-based functions as gcc builtins
I committed the wrong version on Yuao's behalf. This followup adds the
documentation changes -- Jeff.
This patch adds trigonometric pi-based functions as gcc builtins: acospi, asinpi, atan2pi,
atanpi, cospi, sinpi, and tanpi. Latest glibc already provides support for
these functions, which we plan to leverage in future gfortran implementations.
The patch includes two test cases to verify both correct code generation and
function definition.
If approved, I suggest committing this foundational change first. Constant
folding for these builtins will be addressed in subsequent patches.
Best regards,
Yuao
From 9a9683d250078ce1bc687797c26ca05a9e91b350 Mon Sep 17 00:00:00 2001
From: Yuao Ma <c8ef@outlook.com>
Date: Wed, 14 May 2025 22:14:00 +0800
Subject: [PATCH] gcc: add trigonometric pi-based functions as gcc builtins
Add trigonometric pi-based functions as GCC builtins: acospi, asinpi, atan2pi,
atanpi, cospi, sinpi, and tanpi. Latest glibc already provides support for
these functions, which we plan to leverage in future gfortran implementations.
The patch includes two test cases to verify both correct code generation and
function definition.
If approved, I suggest committing this foundational change first. Constant
folding for these builtins will be addressed in subsequent patches.
Yuao Ma [Sat, 17 May 2025 13:42:24 +0000 (07:42 -0600)]
[PATCH] gcc: add trigonometric pi-based functions as gcc builtins
This patch adds trigonometric pi-based functions as gcc builtins: acospi, asinpi, atan2pi,
atanpi, cospi, sinpi, and tanpi. Latest glibc already provides support for
these functions, which we plan to leverage in future gfortran implementations.
The patch includes two test cases to verify both correct code generation and
function definition.
If approved, I suggest committing this foundational change first. Constant
folding for these builtins will be addressed in subsequent patches.
Best regards,
Yuao
From 9a9683d250078ce1bc687797c26ca05a9e91b350 Mon Sep 17 00:00:00 2001
From: Yuao Ma <c8ef@outlook.com>
Date: Wed, 14 May 2025 22:14:00 +0800
Subject: [PATCH] gcc: add trigonometric pi-based functions as gcc builtins
Add trigonometric pi-based functions as GCC builtins: acospi, asinpi, atan2pi,
atanpi, cospi, sinpi, and tanpi. Latest glibc already provides support for
these functions, which we plan to leverage in future gfortran implementations.
The patch includes two test cases to verify both correct code generation and
function definition.
If approved, I suggest committing this foundational change first. Constant
folding for these builtins will be addressed in subsequent patches.
Jeff Law [Sat, 17 May 2025 13:16:50 +0000 (07:16 -0600)]
[RISC-V] Avoid setting output object more than once in IOR/XOR synthesis
While evaluating Shreya's logical AND synthesis work on spec2017 I ran into a
code quality regression where combine was failing to eliminate a redundant sign
extension.
I had a hunch the problem would be with the multiple sets of the same pseudo
register in the AND synthesis path. I was right that the problem was multiple
sets of the same pseudo, but it was actually some of the splitters in the
RISC-V backend that were the culprit. Those multiple sets caused the sign bit
tracking code to need to make conservative assumptions thus resulting in
failure to eliminate the unnecessary sign extension.
So before we start moving on the logical AND patch we're going to do some
cleanups.
There's multiple moving parts in play. For example, we have splitters which do
multiple sets of the output register. Fixing some of those independently would
result in a code quality regression. Instead they need some adjustments to or
removal of mvconst_internal. Of course getting rid of mvconst_internal will
trigger all kinds of code quality regressions right now which ultimately lead
back to the need to revamp the logical AND expander. Point being we've got
some circular dependencies and breaking them may result in short term code
quality regressions. I'll obviously try to avoid those as much as possible.
So to start the process this patch adjusts the recently added XOR/IOR synthesis
to avoid re-using the destination register. While the reuse was clearly safe
from a semantic standpoint, various parts of the compiler can do a better job
for pseudos that are only set once.
Given this synthesis path should only be active during initial RTL generation,
we can create new pseudos at will, so we create a new one for each insn. At
the end of the sequence we copy from the last set into the final destination.
This has various trivial impacts on the code generation, but the resulting code
looks no better or worse to me across spec2017.
This has been tested in my tester and is currently bootstrapping on my BPI.
Waiting on data from the pre-commit tester before moving forward...
gcc/
* config/riscv/riscv.cc (synthesize_ior_xor): Avoid writing
operands[0] more than once, use new pseudos instead.
Pan Li [Fri, 16 May 2025 07:34:51 +0000 (15:34 +0800)]
RISC-V: Avoid scalar unsigned SAT_ADD test data duplication
Some of the previous scalar unsigned SAT_ADD test data are
duplicated in different test files. This patch would like to
move them into a shared header file, to avoid the test data
duplication.
The below test suites are passed for this patch series.
* The rv64gcv fully regression test.
Pengxuan Zheng [Mon, 12 May 2025 17:21:49 +0000 (10:21 -0700)]
aarch64: Add more vector permute tests for the FMOV optimization [PR100165]
This patch adds more tests for vector permutes which can now be optimized as
FMOV with the generic PERM change and the aarch64 AND patch.
Changes since v1:
* v2: Add -mlittle-endian to the little endian tests explicitly and rename the
tests accordingly.
PR target/100165
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/fmov-3-be.c: New test.
* gcc.target/aarch64/fmov-3-le.c: New test.
* gcc.target/aarch64/fmov-4-be.c: New test.
* gcc.target/aarch64/fmov-4-le.c: New test.
* gcc.target/aarch64/fmov-5-be.c: New test.
* gcc.target/aarch64/fmov-5-le.c: New test.
Pengxuan Zheng [Mon, 12 May 2025 17:12:11 +0000 (10:12 -0700)]
aarch64: Optimize AND with certain vector of immediates as FMOV [PR100165]
We can optimize AND with certain vector of immediates as FMOV if the result of
the AND is as if the upper lane of the input vector is set to zero and the lower
lane remains unchanged.
f_v4hi:
movi d31, 0xffffffff
and v0.8b, v0.8b, v31.8b
ret
With this patch, it generates:
f_v4hi:
fmov s0, s0
ret
Changes since v1:
* v2: Simplify the mask checking logic by using native_decode_int and address a
few other review comments.
PR target/100165
gcc/ChangeLog:
* config/aarch64/aarch64-protos.h (aarch64_output_fmov): New prototype.
(aarch64_simd_valid_and_imm_fmov): Likewise.
* config/aarch64/aarch64-simd.md (and<mode>3<vczle><vczbe>): Allow FMOV
codegen.
* config/aarch64/aarch64.cc (aarch64_simd_valid_and_imm_fmov): New.
(aarch64_output_fmov): Likewise.
* config/aarch64/constraints.md (Df): New constraint.
* config/aarch64/predicates.md (aarch64_reg_or_and_imm): Update
predicate to support FMOV codegen.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/fmov-1-be.c: New test.
* gcc.target/aarch64/fmov-1-le.c: New test.
* gcc.target/aarch64/fmov-2-be.c: New test.
* gcc.target/aarch64/fmov-2-le.c: New test.
Pengxuan Zheng [Wed, 7 May 2025 17:47:37 +0000 (10:47 -0700)]
aarch64: Recognize vector permute patterns which can be interpreted as AND [PR100165]
Certain permute that blends a vector with zero can be interpreted as an AND of a
mask. This idea was suggested by Richard Sandiford when he was reviewing my
patch which tries to optimizes certain vector permute with the FMOV instruction
for the aarch64 target.
Pengxuan Zheng [Fri, 16 May 2025 00:52:29 +0000 (17:52 -0700)]
aarch64: Fix an oversight in aarch64_evpc_reencode
Some fields (e.g., zero_op0_p and zero_op1_p) of the struct "newd" may be left
uninitialized in aarch64_evpc_reencode. This can cause reading of uninitialized
data. I found this oversight when testing my patches on and/fmov
optimizations. This patch fixes the bug by zero initializing the struct.
Pushed as obvious after bootstrap/test on aarch64-linux-gnu.
gcc/ChangeLog:
* config/aarch64/aarch64.cc (aarch64_evpc_reencode): Zero initialize
newd.
Patrick Palka [Fri, 16 May 2025 17:06:04 +0000 (13:06 -0400)]
libstdc++: Use __is_invocable/nothrow_invocable builtins more
As a follow-up to r15-1253 and r15-1254 which made us use these builtins
in the standard std::is_invocable/nothrow_invocable class templates, let's
also use them directly in the standard variable templates and our internal
C++11 __is_invocable/nothrow_invocable class templates.
libstdc++-v3/ChangeLog:
* include/std/type_traits (__is_invocable): Define in terms of
corresponding builtin if available.
(__is_nothrow_invocable): Likewise.
(is_invocable_v): Likewise.
(is_nothrow_invocable_v): Likewise.
Andrew Pinski [Thu, 15 May 2025 03:41:22 +0000 (20:41 -0700)]
Forwprop: add a debug dump after propagate into comparison does something
I noticed that fowprop does not dump when forward_propagate_into_comparison
did a change to the assign statement.
I am actually using it to help guide changing/improving/add match patterns
instead of depending on doing a tree "combiner" here.
Bootstrapped and tested on x86_64-linux-gnu.
gcc/ChangeLog:
* tree-ssa-forwprop.cc (forward_propagate_into_comparison): Dump
when replacing statement.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
Martin Jambor [Fri, 16 May 2025 15:13:51 +0000 (17:13 +0200)]
ipa: Dump cgraph_node UID instead of order into ipa-clones dump file
Since starting from GCC 15 the order is not unique for any
symtab_nodes but m_uid is, I believe we ought to dump the latter in
the ipa-clones dump, if only so that people can reliably match entries
about new clones to those about removed nodes (if any).
This patch also contains a fixes to a few other places where we have
so far dumped order to our ordinary dumps and which have been
identified by Michal Jires.
gcc/ChangeLog:
2025-05-16 Martin Jambor <mjambor@suse.cz>
* cgraph.h (symtab_node): Make member function get_uid const.
* cgraphclones.cc (dump_callgraph_transformation): Dump m_uid of the
call graph nodes instead of order.
* cgraph.cc (cgraph_node::remove): Likewise.
* ipa-cp.cc (ipcp_lattice<valtype>::print): Likewise.
* ipa-sra.cc (ipa_sra_summarize_function): Likewise.
* symtab.cc (symtab_node::dump_base): Likewise.
Andrew Pinski [Sat, 10 May 2025 04:13:48 +0000 (21:13 -0700)]
aarch64: Fix narrowing warning in driver-aarch64.cc [PR118603]
Since the AARCH64_CORE defines in aarch64-cores.def all use -1 for
the variant, it is just easier to add the cast to unsigned in the usage
in driver-aarch64.cc.
Build and tested on aarch64-linux-gnu.
gcc/ChangeLog:
PR target/118603
* config/aarch64/driver-aarch64.cc (aarch64_cpu_data): Add cast to unsigned
to VARIANT of the define AARCH64_CORE.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
Andrew Pinski [Sat, 10 May 2025 03:56:42 +0000 (20:56 -0700)]
aarch64: Fix narrowing warning in aarch64_detect_vector_stmt_subtype
There is a narrowing warning in aarch64_detect_vector_stmt_subtype
about gather_load_x32_cost and gather_load_x64_cost converting from int to unsigned.
These fields are always unsigned and even the constructor for sve_vec_cost takes
an unsigned. So let's just move the fields over to unsigned.
Build and tested for aarch64-linux-gnu.
gcc/ChangeLog:
* config/aarch64/aarch64-protos.h (struct sve_vec_cost): Change gather_load_x32_cost
and gather_load_x64_cost fields to unsigned.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
Andrew Pinski [Mon, 21 Apr 2025 19:19:49 +0000 (12:19 -0700)]
forwprop: Move memcpy_to_memset from gimple fold to forwprop
Since this optimization now walks the vops, it is better to only
do it in forwprop rather than in all the time in fold_stmt.
The next patch will add the limit to the alias walk.
gcc/ChangeLog:
* gimple-fold.cc (optimize_memcpy_to_memset): Move to
tree-ssa-forwprop.cc.
(gimple_fold_builtin_memory_op): Remove call to
optimize_memcpy_to_memset.
(fold_stmt_1): Likewise.
* tree-ssa-forwprop.cc (optimize_memcpy_to_memset): Move from
gimple-fold.cc.
(simplify_builtin_call): Try to optimize memcpy/memset.
(pass_forwprop::execute): Try to optimize memcpy like assignment
from a previous memset.
gcc/testsuite/ChangeLog:
* gcc.dg/pr78408-1.c: Update scan to forwprop1 only.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
Iain Sandoe [Sat, 10 May 2025 16:22:55 +0000 (17:22 +0100)]
c++, coroutines: Allow NVRO in more cases for ramp functions.
The constraints of the c++ coroutines specification require the ramp
to construct a return object early in the function. This will be returned
at some later time. This is implemented as NVRO but requires that copying
be well-formed even though it will be elided. Special-case ramp functions
to allow this.
gcc/cp/ChangeLog:
* typeck.cc (check_return_expr): Suppress conversions for NVRO
in coroutine ramp functions.
Iain Sandoe [Sat, 10 May 2025 16:12:44 +0000 (17:12 +0100)]
c++: Set the outer brace marker for missed cases.
In some cases, a function might be declared as FUNCTION_NEEDS_BODY_BLOCK
but all the content is contained within that block. However, poplevel
is currently assuming that such cases would always contain subblocks.
In the case that we do have a body block, but there are no subblocks
then st the outer brace marker on the body block. This situation occurs
for at least coroutine lambda ramp functions and empty constructors.
gcc/cp/ChangeLog:
* decl.cc (poplevel): Set BLOCK_OUTER_CURLY_BRACE_P on the
body block for functions with no subblocks.
Nathaniel Shead [Fri, 28 Mar 2025 12:30:31 +0000 (23:30 +1100)]
c++/modules: Clean up importer_interface
This patch removes some no longer needed special casing in linkage
determination, and makes the distinction between "always_emit" and
"internal" for better future-proofing.
gcc/cp/ChangeLog:
* module.cc (importer_interface): Adjust flags.
(get_importer_interface): Rename flags.
(trees_out::core_bools): Clean up special casing.
(trees_out::write_function_def): Rename flag.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com> Reviewed-by: Jason Merrill <jason@redhat.com>
Jason Merrill [Fri, 16 May 2025 12:22:08 +0000 (08:22 -0400)]
c++: one more coro test tweak
After my r16-670, running the testsuite with explicit --stds didn't run this
one in C++17 mode, but the default did. Let's remove the { target c++17 }
so it doesn't by default, either.
This patch mops up obvious redundancies that weren't caught by the
automatic regexp replacements in earlier patches. It doesn't do
anything with genemit.cc, since that will be part of a later series.
gcc/
* config/arm/arm.cc (arm_gen_load_multiple_1): Simplify use of
end_sequence.
(arm_gen_store_multiple_1): Likewise.
* expr.cc (gen_move_insn): Likewise.
* gentarget-def.cc (main): Likewise.
The start_sequence/end_sequence interface was a big improvement over
the previous state, but one slightly awkward thing about it is that
you have to call get_insns before end_sequence in order to get the
insn sequence itself:
To get the contents of the sequence just made, you must call
`get_insns' *before* calling here.
I can see three main potential objections to this:
(1) It isn't obvious whether ending the sequence would return the first
or the last instruction. But although some code reads *both* the
first and the last instruction, I can't think of a specific case
where code would want *only* the last instruction. All the emit
functions take the first instruction rather than the last.
(2) The "end" in end_sequence might imply the C++ meaning of an exclusive
endpoint iterator. But for an insn sequence, the exclusive endpoint
is always the null pointer, so it would never need to be returned.
That said, we could rename the function to something like
"finish_sequence" or "complete_sequence" if this is an issue.
(3) There might have been an intention that start_sequence/end_sequence
could in future reclaim memory for unwanted sequences, and so an
explicit get_insns was used to indicate that the caller does want
the sequence.
But that sort of memory reclaimation has never been added,
and now that the codebase is C++, it would be easier to handle
using RAII. I think reclaiming memory would be difficult to do in
any case, since some code records the individual instructions that
they emit, rather than using get_insns.
Jonathan Wakely [Thu, 15 May 2025 15:03:53 +0000 (16:03 +0100)]
libstdc++: Fix proc check_v3_target_namedlocale for "" locale [PR65909]
When the last format argument to a Tcl proc is named 'args' it has
special meaning and is a list that accepts any number of arguments[1].
This means when "" is passed to the proc and then we expand "$args" we
get an empty list formatted as "{}". My r16-537-g3e2b83faeb6b14 change
broke all uses of dg-require-namedlocale with empty locale names, "".
By changing the name of the formal argument to 'locale' we avoid the
special behaviour for 'args' and now it only accepts a single argument
(as was always intended). When expanded as "$locale" we get "" as I
expected.
Pan Li [Tue, 13 May 2025 03:12:53 +0000 (11:12 +0800)]
RISC-V: Adjust vx combine test case to avoid name conflict
Given we will put all vx combine for int8 in a single file,
we need to make sure the generate function for different
types and ops has different function name. Thus, refactor
the test helper macros for avoiding possible function name
conflict.
The below test suites are passed for this patch series.
* The rv64gcv fully regression test.
Pan Li [Sun, 11 May 2025 08:20:28 +0000 (16:20 +0800)]
RISC-V: Combine vec_duplicate + vsub.vv to vsub.vx on GR2VR cost
This patch would like to combine the vec_duplicate + vsub.vv to the
vsub.vx. From example as below code. The related pattern will depend
on the cost of vec_duplicate from GR2VR. Then the late-combine will
take action if the cost of GR2VR is zero, and reject the combination
if the GR2VR cost is greater than zero.
Assume we have example code like below, GR2VR cost is 0.
#define DEF_VX_BINARY(T, OP) \
void \
test_vx_binary (T * restrict out, T * restrict in, T x, unsigned n) \
{ \
for (unsigned i = 0; i < n; i++) \
out[i] = in[i] OP x; \
}
The below test suites are passed for this patch.
* The rv64gcv fully regression test.
gcc/ChangeLog:
* config/riscv/autovec-opt.md (*<optab>_vx_<mode>): Add new
pattern to convert vec_duplicate + vsub.vv to vsub.vx.
* config/riscv/riscv.cc (riscv_rtx_costs): Add minus as plus op.
* config/riscv/vector-iterators.md: Add minus to iterator
any_int_binop_no_shift_vx.
Jason Merrill [Sat, 10 May 2025 15:24:38 +0000 (11:24 -0400)]
c++: remove coroutines.exp
coroutines.exp was basically only there to add -std=c++20 to all the tests;
removing it lets us use the general support for running tests under multiple
standards. Doing this revealed that some tests that specifically run in
C++17 mode were relying on -std=c++20 followed by -std=c++17 leaving
flag_coroutines set, which seems unintentional, and different from how we
handle other feature flags. So this changes that, and adds the missing
-fcoroutines to those tests.
Harald Anlauf [Thu, 15 May 2025 19:07:07 +0000 (21:07 +0200)]
Fortran: default-initialization and functions returning derived type [PR85750]
Functions with non-pointer, non-allocatable result and of derived type did
not always get initialized although the type had default-initialization,
and a derived type component had the allocatable or pointer attribute.
Rearrange the logic when to apply default-initialization.
PR fortran/85750
gcc/fortran/ChangeLog:
* resolve.cc (resolve_symbol): Reorder conditions when to apply
default-initializers.
Andrew MacLeod [Wed, 14 May 2025 15:13:15 +0000 (11:13 -0400)]
Allow bitmask intersection to process unknown masks.
bitmask_intersection should not return immediately if the current mask is
unknown. Unknown may mean its the default for a range, and this may
interact in intersting ways with the other bitmask.
PR tree-optimization/116546
* value-range.cc (irange::intersect_bitmask): Allow unknown
bitmasks to be processed.
Andrew MacLeod [Wed, 14 May 2025 15:12:22 +0000 (11:12 -0400)]
Improve constant bitmasks.
bitmasks for constants are created only for trailing zeros. It is no
additional work to also include leading 1's in the value that are also
known.
before : [5, 7] mask 0x7 value 0x0
after : [5, 7] mask 0x3 value 0x4
PR tree-optimization/116546
* value-range.cc (irange_bitmask::irange_bitmask): Include
leading ones in the bitmask.
Andrew MacLeod [Tue, 13 May 2025 17:23:16 +0000 (13:23 -0400)]
Turn get_bitmask_from_range into an irange_bitmask constructor.
There are other places where this is interesting, so move the static
function into a constructor for class irange_bitmask.
* value-range.cc (irange_bitmask::irange_bitmask): Rename from
get_bitmask_from_range and tweak.
(prange::set): Use new constructor.
(prange::intersect): Use new constructor.
(irange::get_bitmask): Likewise.
* value-range.h (irange_bitmask): New constructor prototype.
projects / thirdparty / gcc.git / log
