Patrick Palka [Thu, 20 Feb 2025 03:59:49 +0000 (22:59 -0500)]
libstdc++: Sync concat_view with final P2542 revision [PR115209]
Our concat_view implementation is accidentally based off of an older
revision of the paper, P2542R7 instead of R8. As far as I can tell the
only semantic change in the final revision is the relaxed constraints on
the iterator's iter/sent operator- overloads, which this patch updates.
This patch also simplifies the concat_view::end wording via C++26 pack
indexing as per the final revision. In turn we make the availability of
this library feature conditional on __cpp_pack_indexing. (Note pack
indexing is implemented in GCC 15 and Clang 19).
PR libstdc++/115209
libstdc++-v3/ChangeLog:
* include/bits/version.def (ranges_concat): Depend on
__cpp_pack_indexing.
* include/bits/version.h: Regenerate.
* include/std/ranges (__detail::__last_is_common): Remove.
(__detail::__all_but_first_sized): New.
(concat_view::end): Use C++26 pack indexing instead of
__last_is_common as per R8 of P2542.
(concat_view::iterator::operator-): Update constraints on
iter/sent overloads as per R8 of P2542.
Thomas Schwinge [Wed, 19 Feb 2025 08:30:45 +0000 (09:30 +0100)]
GCN, nvptx: Support '--enable-languages=all'
..., where "support" means that the build doesn't fail, but it doesn't mean
that all target libraries get built and we get pretty test results for the
additional languages.
Andrew Pinski [Wed, 19 Feb 2025 03:02:40 +0000 (19:02 -0800)]
aarch64: Fix testcase pr112105.c
This testcase started to fail with r15-268-g9dbff9c05520a7.
When late_combine was added, it was turned on for -O2+ only,
so this testcase still failed.
This changes the option to be -O2 instead of -O and the testcase
started to pass again.
tested for aarch64-linux-gnu.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/pr112105.c: Change to be -O2 rather
than -O1.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
David Malcolm [Wed, 19 Feb 2025 14:46:43 +0000 (09:46 -0500)]
input: give file_cache_slot its own copy of the file path [PR118919]
input.cc's file_cache was borrowing copies of the file name.
This could lead to use-after-free when writing out sarif output
from Fortran, which frees its filenames before the sarif output
is fully written out.
Fix by taking a copy in file_cache_slot.
gcc/ChangeLog:
PR other/118919
* input.cc (file_cache_slot::m_file_path): Make non-const.
(file_cache_slot::evict): Free m_file_path.
(file_cache_slot::create): Store a copy of file_path if non-null.
(file_cache_slot::~file_cache_slot): Free m_file_path.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
David Malcolm [Wed, 19 Feb 2025 14:44:46 +0000 (09:44 -0500)]
analyzer: handle more IFN_UBSAN_* as no-ops [PR118300]
Previously the analyzer treated IFN_UBSAN_BOUNDS as a no-op, but
the other IFN_UBSAN_* were unrecognized and conservatively treated
as having arbitrary behavior.
Treat IFN_UBSAN_NULL and IFN_UBSAN_PTR also as no-ops, which should
make -fanalyzer behave better with -fsanitize=undefined.
gcc/analyzer/ChangeLog:
PR analyzer/118300
* kf.cc (class kf_ubsan_bounds): Replace this with...
(class kf_ubsan_noop): ...this.
(register_sanitizer_builtins): Use it to handle IFN_UBSAN_NULL,
IFN_UBSAN_BOUNDS, and IFN_UBSAN_PTR as nop-ops.
(register_known_functions): Drop handling of IFN_UBSAN_BOUNDS
here, as it's now handled by register_sanitizer_builtins above.
gcc/testsuite/ChangeLog:
PR analyzer/118300
* gcc.dg/analyzer/ubsan-pr118300.c: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
Pan Li [Wed, 19 Feb 2025 01:37:51 +0000 (09:37 +0800)]
Vect: Fix ICE when vect_verify_loop_lens acts on relevant mode [PR116351]
This patch would like to fix the ICE similar as below, assump we have
sample code:
1 │ int a, b, c;
2 │ short d, e, f;
3 │ long g (long h) { return h; }
4 │
5 │ void i () {
6 │ for (; b; ++b) {
7 │ f = 5 >> a ? d : d << a;
8 │ e &= c | g(f);
9 │ }
10 │ }
It will ice when compile with -O3 -march=rv64gc_zve64f -mrvv-vector-bits=zvl
During vectorization the override_widen pattern matched and then will get DImode
as vector_mode in loop_info. After that the loop_vinfo will step in vect_analyze_xx
with below flow:
vect_analyze_loop_2
|- vect_pattern_recog // over-widening and set loop_vinfo->vector_mode to DImode
|- ...
|- vect_analyze_loop_operations
|- stmt_info->def_type == vect_reduction_def
|- stmt_info->slp_type == pure_slp
|- vectorizable_lc_phi // Not Hit
|- vectorizable_induction // Not Hit
|- vectorizable_reduction // Not Hit
|- vectorizable_recurr // Not Hit
|- vectorizable_live_operation // Not Hit
|- vect_analyze_stmt
|- stmt_info->relevant == vect_unused_in_scope
|- stmt_info->live == false
|- p pattern_stmt_info == (stmt_vec_info) 0x0
|- return opt_result::success ();
OR
|- PURE_SLP_STMT (stmt_info) && !node then dump "handled only by SLP analysis\n"
|- Early return opt_result::success ();
|- vectorizable_load/store/call_convert/... // Not Hit
|- LOOP_VINFO_CAN_USE_PARTIAL_VECTORS_P && !LOOP_VINFO_MASKS(loop_vinfo).is_empty ()
|- vect_verify_loop_lens (loop_vinfo)
|- assert (VECTOR_MODE_P (loop_vinfo->vector_mode); // Hit assert result in ICE
Finally, the DImode in loop_vinfo will hit the assert (VECTOR_MODE_P (mode))
in vect_verify_loop_lens. This patch would like to return false
directly if the loop_vinfo has relevant mode like DImode for the ICE
fix, but still may have mis-optimization for similar cases. We will try
to cover that in separated patches.
The below test suites are passed for this patch.
* The rv64gcv fully regression test.
* The x86 bootstrap test.
* The x86 fully regression test.
PR middle-end/116351
gcc/ChangeLog:
* tree-vect-loop.cc (vect_verify_loop_lens): Return false if the
loop_vinfo has relevant mode such as DImode.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/pr116351-1.c: New test.
* gcc.target/riscv/rvv/base/pr116351-2.c: New test.
* gcc.target/riscv/rvv/base/pr116351.h: New test.
Xi Ruoyao [Mon, 20 Jan 2025 15:13:19 +0000 (23:13 +0800)]
LoongArch: Implement [su]dot_prod* for LSX and LASX modes
Despite it's just a special case of "a widening product of which the
result used for reduction," having these standard names allows to
recognize the dot product pattern earlier and it may be beneficial to
optimization. Also fix some test failures with the test cases:
Xi Ruoyao [Mon, 20 Jan 2025 12:43:07 +0000 (20:43 +0800)]
LoongArch: Implement vec_widen_mult_{even,odd}_* for LSX and LASX modes
Since PR116142 has been fixed, now we can add the standard names so the
compiler will generate better code if the result of a widening
production is reduced.
gcc/ChangeLog:
* config/loongarch/simd.md (even_odd): New define_int_attr.
(vec_widen_<su>mult_<even_odd>_<mode>): New define_expand.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/wide-mul-reduc-1.c: New test.
* gcc.target/loongarch/wide-mul-reduc-2.c: New test.
Xi Ruoyao [Tue, 11 Feb 2025 18:42:58 +0000 (02:42 +0800)]
LoongArch: Simplify lsx_vpick description
Like what we've done for {lsx_,lasx_x}v{add,sub,mul}l{ev,od}, use
special predicates instead of hard-coded const vectors.
This is not suitable for LASX where lasx_xvpick has a different
semantic.
gcc/ChangeLog:
* config/loongarch/simd.md (LVEC): New define_mode_attr.
(simdfmt_as_i): Make it same as simdfmt for integer vector
modes.
(_f): New define_mode_attr.
* config/loongarch/lsx.md (lsx_vpickev_b): Remove.
(lsx_vpickev_h): Remove.
(lsx_vpickev_w): Remove.
(lsx_vpickev_w_f): Remove.
(lsx_vpickod_b): Remove.
(lsx_vpickod_h): Remove.
(lsx_vpickod_w): Remove.
(lsx_vpickev_w_f): Remove.
(lsx_pick_evod_<mode>): New define_insn.
(lsx_<x>vpick<ev_od>_<simdfmt_as_i><_f>): New
define_expand.
These pattern definitions are tediously long, invoking 32 UNSPECs and
many hard-coded long const vectors. To simplify them, at first we use
the TImode vector operations instead of the UNSPECs, then we adopt an
approach in AArch64: using a special predicate to match the const
vectors for odd/even indices for define_insn's, and generate those
vectors in define_expand's.
For "backward compatibilty" we need to provide a "punned" version for
the operations invoking TImode vectors as the intrinsics still expect
DImode vectors.
Xi Ruoyao [Fri, 24 Jan 2025 00:33:39 +0000 (08:33 +0800)]
LoongArch: Allow moving TImode vectors
We have some vector instructions for operations on 128-bit integer, i.e.
TImode, vectors. Previously they had been modeled with unspecs, but
it's more natural to just model them with TImode vector RTL expressions.
For the preparation, allow moving V1TImode and V2TImode vectors in LSX
and LASX registers so we won't get a reload failure when we start to
save TImode vectors in these registers.
This implicitly depends on the vrepli optimization: without it we'd try
"vrepli.q" which does not really exist and trigger an ICE.
gcc/ChangeLog:
* config/loongarch/lsx.md (mov<LSX:mode>): Remove.
(movmisalign<LSX:mode>): Remove.
(mov<LSX:mode>_lsx): Remove.
* config/loongarch/lasx.md (mov<LASX:mode>): Remove.
(movmisalign<LASX:mode>): Remove.
(mov<LASX:mode>_lasx): Remove.
* config/loongarch/loongarch-modes.def (V1TI): Add.
(V2TI): Mention in the comment.
* config/loongarch/loongarch.md (mode): Add V1TI and V2TI.
* config/loongarch/simd.md (ALLVEC_TI): New mode iterator.
(mov<ALLVEC_TI:mode): New define_expand.
(movmisalign<ALLVEC_TI:mode>): Likewise.
(mov<ALLVEC_TI:mode>_simd): New define_insn_and_split.
Xi Ruoyao [Fri, 24 Jan 2025 00:32:18 +0000 (08:32 +0800)]
LoongArch: Try harder using vrepli instructions to materialize const vectors
For
a = (v4si){0xdddddddd, 0xdddddddd, 0xdddddddd, 0xdddddddd}
we just want
vrepli.b $vr0, 0xdd
but the compiler actually produces a load:
la.local $r14,.LC0
vld $vr0,$r14,0
It's because we only tried vrepli.d which wouldn't work. Try all vrepli
instructions for const int vector materializing to fix it.
gcc/ChangeLog:
* config/loongarch/loongarch-protos.h
(loongarch_const_vector_vrepli): New function prototype.
* config/loongarch/loongarch.cc (loongarch_const_vector_vrepli):
Implement.
(loongarch_const_insns): Call loongarch_const_vector_vrepli
instead of loongarch_const_vector_same_int_p.
(loongarch_split_vector_move_p): Likewise.
(loongarch_output_move): Use loongarch_const_vector_vrepli to
pun operend[1] into a better mode if it's a const int vector,
and decide the suffix of [x]vrepli with the new mode.
* config/loongarch/constraints.md (YI): Call
loongarch_const_vector_vrepli instead of
loongarch_const_vector_same_int_p.
Xi Ruoyao [Mon, 10 Feb 2025 15:39:24 +0000 (23:39 +0800)]
LoongArch: Accept ADD, IOR or XOR when combining objects with no bits in common [PR115478]
Since r15-1120, multi-word shifts/rotates produces PLUS instead of IOR.
It's generally a good thing (allowing to use our alsl instruction or
similar instrunction on other architectures), but it's preventing us
from using bytepick. For example, if we shift a __int128 by 16 bits,
the higher word can be produced via a single bytepick.d instruction with
immediate 2, but we got:
srli.d $r12,$r4,48
slli.d $r5,$r5,16
slli.d $r4,$r4,16
add.d $r5,$r12,$r5
jr $r1
This wasn't work with GCC 14, but after r15-6490 it's supposed to work
if IOR was used instead of PLUS.
To fix this, add a code iterator to match IOR, XOR, and PLUS and use it
instead of just IOR if we know the operands have no overlapping bits.
gcc/ChangeLog:
PR target/115478
* config/loongarch/loongarch.md (any_or_plus): New
define_code_iterator.
(bstrins_<mode>_for_ior_mask): Use any_or_plus instead of ior.
(bytepick_w_<bytepick_imm>): Likewise.
(bytepick_d_<bytepick_imm>): Likewise.
(bytepick_d_<bytepick_imm>_rev): Likewise.
gcc/testsuite/ChangeLog:
PR target/115478
* gcc.target/loongarch/bytepick_shift_128.c: New test.
Jeff Law [Wed, 19 Feb 2025 02:45:29 +0000 (19:45 -0700)]
[PR middle-end/113525] Drop obsolete options from documentation
The sibling and unshare passes were dropped as distinct passes 10+ years ago.
Docs weren't ever updated. This just removes them; given their age I don't
think we need to keep them around any longer.
PR middle-end/113525
gcc/
* doc/invoke.texi (dump-rtl-sibling): Drop documentation for pass
removed long ago.
(dump-rtl-unshare): Likewise.
David Malcolm [Tue, 18 Feb 2025 21:54:57 +0000 (16:54 -0500)]
analyzer: add more properties to sarif output
Add some more properties to the analyzer's sarif output, to
help with debugging -fanalyzer.
gcc/analyzer/ChangeLog:
* diagnostic-manager.cc
(saved_diagnostic::maybe_add_sarif_properties): Add various
properties for debugging, for m_stmt, m_var, and m_duplicates.
Remove stray 'if' statement. Capture the kind of the
pending_diagnostic.
* region-model.cc
(poisoned_value_diagnostic::maybe_add_sarif_properties): New.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
David Malcolm [Tue, 18 Feb 2025 21:54:52 +0000 (16:54 -0500)]
sarif output: fix alphabetization in sarif_scheme_handler::make_sink
No functional change intended.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
gcc/ChangeLog:
* opts-diagnostic.cc (sarif_scheme_handler::make_sink): Put
properties in alphabetical order.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
Roman Kagan [Thu, 2 Jan 2025 15:32:17 +0000 (16:32 +0100)]
libgcc: i386/linux-unwind.h: always rely on sys/ucontext.h
When gcc is built for x86_64-linux-musl target, stack unwinding from
within signal handler stops at the innermost signal frame. The reason
for this behaviro is that the signal trampoline is not accompanied with
appropiate CFI directives, and the fallback path in libgcc to recognize
it by the code sequence is only enabled for glibc except 2.0. The
latter is motivated by the lack of sys/ucontext.h in that glibc version.
Given that all relevant libc-s ship sys/ucontext.h for over a decade,
and that other arches aren't shy of unconditionally using it, follow
suit and remove the preprocessor condition, too.
libgcc/ChangeLog:
* config/i386/linux-unwind.h: Remove preprocessor
condition to enable fallback path for all libc-s.
The result is vsetvl zero, zero, e64, mf2, ta, ma. The previous vsetvl
set vl = 4 but here we wrongly set it to vl = 2. As all the following
vsetvls only ever change the ratio we never recover.
The issue is quite difficult to trigger because we can often
deduce the value of d at runtime. Then very check for the value of
d will be optimized away.
The last known bad commit is r15-3458-g5326306e7d9d36. With that commit
the output is wrong but -fno-schedule-insns makes it correct. From the
next commit on the issue is latent. I still added the PR's test as scan
and run check even if they don't trigger right now. Not sure if the
run test will ever fail but well. I verified that the
patch fixes the issue when applied on top of r15-3458-g5326306e7d9d36.
PR target/115703
gcc/ChangeLog:
* config/riscv/riscv-vsetvl.cc: Use max_sew for calculating the
new LMUL.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/autovec/pr115703-run.c: New test.
* gcc.target/riscv/rvv/autovec/pr115703.c: New test.
Tobias Burnus [Tue, 18 Feb 2025 14:48:39 +0000 (15:48 +0100)]
gfortran.dg/gomp/metadirective-3.f90: xfail on offload_nvptx
Currently, 'target' with a nested metadirective creating a 'teams' will
fail with a bogus error ("‘target’ construct with nested ‘teams’ construct
contains directives outside of the ‘teams’ construct").
That's tracked at PR118694 - and, hence, expected.
However, the testcase metadirective-3.f90 triggers this when compiling for
'target offload_nvptx' (otherwise, the code is optimized away). Use xfail to
silence the error as it is known and there is a tracking PR.
gcc/testsuite/ChangeLog:
* gfortran.dg/gomp/metadirective-3.f90: Add xfail when
compiling for offload_nvptx.
late-combine: Tighten register class check [PR108840]
gcc.target/aarch64/pr108840.c has failed since r15-268-g9dbff9c05520
(which means that I really ought to have looked at it earlier).
The test wants us to fold an SImode AND into all shifts that use it.
This is something that late-combine is supposed to do, but:
(1) the pre-RA pass chickened out because of a register pressure check
(2) the post-RA pass can't handle it, because the shift uses are in
QImode and the sets are in SImode
Both are things that would be good to fix. But (1) is particularly
silly. The constraints on the AND have "rk" for the destination
(so allowing the stack pointer) and "r" for the first source.
Including the stack pointer made the destination seem more permissive
than the source.
The intention was instead to check whether there are any
*allocatable* registers in the destination class that aren't
present in the source.
That's enough for all tests but the last one. The last one still
fails because combine merges the final shift with the move into
the hard return register, giving an arithmetic instruction with
a hard register destination. Pre-RA late-combine currently punts
on those, again due to register pressure concerns. That too is
something I'd like to relax, but not for GCC 15. In the interim,
the best thing seems to be to disable combine for the test.
gcc/
PR rtl-optimization/108840
* late-combine.cc (late_combine::check_register_pressure):
Take only allocatable registers into account when checking
the permissiveness of register classes.
gcc/testsuite/
PR rtl-optimization/108840
* gcc.target/aarch64/pr108840.c: Run at -O2 but disable combine.
Alex Coplan [Tue, 18 Feb 2025 10:48:50 +0000 (10:48 +0000)]
pair-fusion: Tweak wording in dump message [PR118320]
As discussed in
https://gcc.gnu.org/pipermail/gcc-patches/2025-February/675978.html
this tweaks the dump messasge added with the fix for PR118320 since it doesn't
just apply to load pairs.
gcc/ChangeLog:
PR rtl-optimization/118320
* pair-fusion.cc (pair_fusion_bb_info::fuse_pair): Tweak wording in dump
message when punting on invalid use arrays.
Richard Biener [Mon, 17 Feb 2025 14:53:11 +0000 (15:53 +0100)]
tree-optimization/98845 - ICE with tail-merging and DCE/DSE disabled
The following shows that tail-merging will make dead SSA defs live
in paths where it wasn't before, possibly introducing UB or as
in this case, uses of abnormals that eventually fail coalescing
later. The fix is to register such defs for stmt comparison.
PR tree-optimization/98845
* tree-ssa-tail-merge.cc (stmt_local_def): Consider a
def with no uses not local.
* gcc.dg/pr98845.c: New testcase.
* gcc.dg/pr81192.c: Adjust.
Pan Li [Sat, 15 Feb 2025 06:33:35 +0000 (14:33 +0800)]
RISC-V: Fix ICE for target attributes has different xlen size
This patch would like to avoid the ICE when the target attribute
specific the xlen different to the cmd. Aka compile with rv64gc
but target attribute with rv32gcv_zbb. For example as blow:
1 │ long foo (long a, long b)
2 │ __attribute__((target("arch=rv32gcv_zbb")));
3 │
4 │ long foo (long a, long b)
5 │ {
6 │ return a + (b * 2);
7 │ }
when compile with rv64gc -O3, it will have ICE similar as below
Consider stage 4, we just report error for the above scenario when
detect the cmd xlen is different to the target attribute during the
target hook TARGET_OPTION_VALID_ATTRIBUTE_P implementation.
PR target/118540
gcc/ChangeLog:
* config/riscv/riscv-target-attr.cc (riscv_target_attr_parser::parse_arch):
Report error when cmd xlen is different with target attribute.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/rvv/base/pr118540-1.c: New test.
* gcc.target/riscv/rvv/base/pr118540-2.c: New test.
Alexandre Oliva [Tue, 18 Feb 2025 02:17:21 +0000 (23:17 -0300)]
[ifcombine] cope with signbit tests of extended values
A compare with zero may be taken as a sign bit test by
fold_truth_andor_for_ifcombine, but the operand may be extended from a
narrower field. If the operand was narrower, the bitsize will reflect
the narrowing conversion, but if it was wider, we'll only know whether
the field is sign- or zero-extended from unsignedp, but we won't know
whether it needed to be extended, because arg will have changed to the
narrower variable when we get to the point in which we can compute the
arg width. If it's sign-extended, we're testing the right bit, but if
it's zero-extended, there isn't any bit we can test.
Instead of punting and leaving the foldable compare to be figured out
by another pass, arrange for the sign bit resulting from the widening
zero-extension to be taken as zero, so that the modified compare will
yield the desired result.
While at that, avoid swapping the right-hand compare operands when
we've already determined that it was a signbit test: it no use to even
try.
for gcc/ChangeLog
PR tree-optimization/118805
* gimple-fold.cc (fold_truth_andor_for_combine): Detect and
cope with zero-extension in signbit tests. Reject swapping
right-compare operands if rsignbit.
Tobias Burnus [Mon, 17 Feb 2025 21:52:34 +0000 (22:52 +0100)]
OpenMP/Fortran: extend 'adjust_args' clause, fixes for it and declare variant [PR115271]
On the extension side, it implements OpenMP 6.0's numeric values/ranges for
the adjust_args arguments, including 'omp_num_args'. And it adds parser
support for need_device_addr. It also implements the post-OpenMP-6.0
clarification of OpenMP spec Issue #4443 regarding type(c_ptr) with
dimension being invalid for need_device_ptr.
To be done: Adding full support for need_device_addr (optional, array
descriptor, ...).
On the invalid side, it removed a bogus c_ptr check that went through
all adjust_args without checking for need_device_ptr and the current scope.
And it finally also processes 'declare variant' in an INTERFACE block,
which is part of PR115271, but it does not handle .mod file yet - the
main issue tracked in that PR.
PR fortran/115271
gcc/fortran/ChangeLog:
* gfortran.h (gfc_omp_namelist): Change need_device_ptr to adj_args
union and add more flags.
* openmp.cc (gfc_match_omp_declare_variant,
gfc_resolve_omp_declare): For adjust_args, handle need_device_addr
and numeric values/ranges besides dummy argument names.
(resolve_omp_dispatch): Remove bogus a adjust_args check.
* trans-decl.cc (gfc_handle_omp_declare_variant): New.
(gfc_generate_module_vars, gfc_generate_function_code): Call it.
* trans-openmp.cc (gfc_trans_omp_declare_variant): Handle numeric
values/ranges besides dummy argument names.
gcc/testsuite/ChangeLog:
* gfortran.dg/gomp/adjust-args-1.f90: Update dg-.* expectations.
* gfortran.dg/gomp/adjust-args-2.f90: Likewise.
* gfortran.dg/gomp/adjust-args-2a.f90: Likewise.
* gfortran.dg/gomp/adjust-args-3.f90: Likewise.
* gfortran.dg/gomp/adjust-args-4.f90: Remove array from c_ptr.
* gfortran.dg/gomp/adjust-args-5.f90: Likewise.
* gfortran.dg/gomp/adjust-args-11.f90: Likewise. Add check that
INTERFACE is now handled in subroutines and in modules.
* gfortran.dg/gomp/adjust-args-13.f90: New test.
* gfortran.dg/gomp/adjust-args-14.f90: New test.
* gfortran.dg/gomp/adjust-args-15.f90: New test.
* gfortran.dg/gomp/declare-variant-21.f90: New test.
Uros Bizjak [Mon, 17 Feb 2025 19:47:14 +0000 (20:47 +0100)]
i386: Simplify PARALLEL RTX scan in ix86_find_all_reg_use
UNSPEC and UNSPEC_VOLATILE never store. Remove unnecessary checks and
simplify RTX scan in ix86_find_all_reg_use to scan only for SET RTX
in the PARALLEL.
gcc/ChangeLog:
* config/i386/i386.cc (ix86_find_all_reg_use):
Scan only for SET RTX in PARALLEL.
Jason Merrill [Sun, 16 Feb 2025 10:00:36 +0000 (11:00 +0100)]
c++: extended temps and statement-exprs [PR118763]
My last patch for 118856 broke the test for 118763 (which my testing didn't
catch, for some reason), because it effectively reverted Jakub's recent fix
(r15-7415) for that bug. It seems we need a new flag to indicate internal
temporaries.
In that patch Jakub wondered if other uses of CLEANUP_EH_ONLY would have the
same issue with jumps out of a statement-expr, and indeed it seems that
maybe_push_temp_cleanup and now set_up_extended_ref_temp have the same
problem. Since maybe_push_temp_cleanup already uses a flag, we can easily
stop setting CLEANUP_EH_ONLY there as well. Since set_up_extended_ref_temp
doesn't, working around this issue there will be more involved.
PR c++/118856
PR c++/118763
gcc/cp/ChangeLog:
* cp-tree.h (TARGET_EXPR_INTERNAL_P): New.
* call.cc (extend_temps_r): Check it instead of CLEANUP_EH_ONLY.
* tree.cc (get_internal_target_expr): Set it instead.
* typeck2.cc (maybe_push_temp_cleanup): Don't set CLEANUP_EH_ONLY.
Richard Biener [Mon, 17 Feb 2025 10:40:01 +0000 (11:40 +0100)]
tree-optimization/118895 - ICE during PRE
When we simplify a NARY during PHI translation we have to make sure
to not inject not available operands into it given that might violate
the valueization hook constraints and we'd pick up invalid
context-sensitive data in further simplification or as in this case
later ICE when we try to insert the expression.
PR tree-optimization/118895
* tree-ssa-sccvn.cc (vn_nary_build_or_lookup_1): Only allow
CSE if we can verify the result is available.
When making warnings trigger a failure in template substitution I
could not find any way to trigger the warning about builtin speculation
not being available on the given target.
Turns out I misread the code -- this warning happens when the
speculation_barrier pattern is not defined.
Here we add an effective target to represent
"__builtin_speculation_safe_value is available on this target" and use
that to adjust our test on SFINAE behaviour accordingly.
N.b. this means that we get extra testing -- not just that things work
on targets which support __builtin_speculation_safe_value, but also that
the behaviour works on targets which don't support it.
Tested with AArch64 native, AArch64 cross compiler, and RISC-V cross
compiler (just running the tests that I've changed).
Ok for trunk?
gcc/testsuite/ChangeLog:
PR target/117991
* g++.dg/template/builtin-speculation-overloads.def: SUCCESS
argument in SPECULATION_ASSERTS now uses a macro `true_def`
instead of the literal `true` for arguments which should work
with `__builtin_speculation_safe_value`.
* g++.dg/template/builtin-speculation-overloads1.C: Define
`true_def` macro on command line to compiler according to the
effective target representing that
`__builtin_speculation_safe_value` does something on this
target.
* g++.dg/template/builtin-speculation-overloads4.C: Likewise.
* lib/target-supports.exp
(check_effective_target_speculation_barrier_defined): New.
Signed-off-by: Matthew Malcomson <mmalcomson@nvidia.com>
Thomas Koenig [Sun, 16 Feb 2025 11:15:40 +0000 (12:15 +0100)]
Avoid shift wider than unsigned HOST_WIDE_INT on unsigned integer exponentiation.
this patch is a variation of Jakub's patch in the PR, which
avoids overflow on the mask used for exponentiation and
fixes unsigned HOST_WIDE_INT. I tried testing this on
a POWER machine, but --with-build-config=bootstrap-ubsan
fails bootstrap there.
gcc/fortran/ChangeLog:
PR fortran/118862
* trans-expr.cc (gfc_conv_cst_int_power): Use functions for
unsigned wide integer.
(gfc_conv_cst_uint_power): Avoid generating the mask if it would
overflow an unsigned HOST_WIDE_INT. Format fixes.
Haochen Jiang [Tue, 11 Feb 2025 03:29:43 +0000 (11:29 +0800)]
i386: Re-alias avx10.2 to 512 bit and deprecate -mno-avx10.2-[256,512]
As mentioned in avx10.1 option deprecate patch, based on the feedback
we got, we would like to re-alias avx10.x to 512 bit.
For -mno- options, also mentioned in the previous patch, it is confusing
what it is disabling when it comes to avx10. So we will only provide
-mno-avx10.x options from AVX10.2, disabling the whole AVX10.x.
gcc/ChangeLog:
* common/config/i386/i386-common.cc
(OPTION_MASK_ISA2_AVX10_1_UNSET): Adjust macro.
(OPTION_MASK_ISA2_AVX10_2_256_UNSET): Removed.
(OPTION_MASK_ISA2_AVX10_2_512_UNSET): Ditto.
(OPTION_MASK_ISA2_AVX10_2_UNSET): New.
(ix86_handle_option): Remove disable part for avx10.2-256.
Rename avx10.2-512 switch case to avx10.2 and adjust disable
part macro.
* common/config/i386/i386-isas.h: Adjust avx10.2 and
avx10.2-512.
* config/i386/driver-i386.cc
(host_detect_local_cpu): Do not append -mno-avx10.x-256
for -march=native.
* config/i386/i386-options.cc
(ix86_valid_target_attribute_inner_p): Adjust avx10.2 and
avx10.2-512.
* config/i386/i386.opt: Reject Negative for mavx10.2-256.
Alias mavx10.2-512 to mavx10.2. Reject Negative for
mavx10.2-512.
* doc/extend.texi: Adjust documentation.
* doc/sourcebuild.texi: Ditto.
Haochen Jiang [Tue, 11 Feb 2025 03:29:34 +0000 (11:29 +0800)]
i386: Deprecate -m[no-]avx10.1 and make -mno-avx10.1-512 to disable the whole AVX10.1
Based on the feedback we got, we would like to re-alias avx10.x to 512
bit in the future. This leaves the current avx10.1 alias to 256 bit
inconsistent. Since it has been there for GCC 14.1 and GCC 14.2,
we decide to deprecate avx10.1 alias. The current proposal is not
adding it back in the future, but it might change if necessary.
For -mno- options, it is confusing what it is disabling when it comes
to avx10. Since there is barely usage enabling AVX10 with 512 bit
then disabling it, we will only provide -mno-avx10.x options in the
future, disabling the whole AVX10.x. If someone really wants to disable
512 bit after enabling it, -mavx10.x-512 -mno-avx10.x -mavx10.x-256 is
the only way to do that since we also do not want to break the usual
expression on -m- options enabling everything mentioned.
However, for avx10.1, since we deprecated avx10.1, there is no reason
we should have -mno-avx10.1. Thus, we need to keep -mno-avx10.1-[256,512].
To avoid confusion, we will make -mno-avx10.1-512 to disable the
whole AVX10.1 set to match the future -mno-avx10.x.
Haochen Jiang [Mon, 10 Feb 2025 08:53:27 +0000 (16:53 +0800)]
i386: Do not check vector size conflict when AVX512 is not explicitly set [PR 118815]
When AVX512 is not explicitly set, we should not take EVEX512 bit into
consideration when checking vector size. It will solve the intrin header
file reporting warnings when compiling with -Wsystem-headers.
However, there is side effect on the usage for '-march=xxx -mavx10.1-256',
where xxx is with AVX512. It will not report warning on vector size for now.
Since it is a rare usage, we will take it.
gcc/ChangeLog:
PR target/118815
* config/i386/i386-options.cc (ix86_option_override_internal):
Do not check vector size conflict when AVX512 is not explicitly
set.
gcc/testsuite/ChangeLog:
PR target/118815
* gcc.target/i386/pr118815.c: New test.
Lulu Cheng [Wed, 12 Feb 2025 06:29:58 +0000 (14:29 +0800)]
LoongArch: Fix the issue of function jump out of range caused by crtbeginS.o [PR118844].
Due to the presence of R_LARCH_B26 in
/usr/lib/gcc/loongarch64-linux-gnu/14/crtbeginS.o, its addressing
range is [PC-128MiB, PC+128MiB-4]. This means that when the code
segment size exceeds 128MB, linking with lld will definitely fail
(ld will not fail because the order of the two is different).
Jakub Jelinek [Sun, 16 Feb 2025 18:19:20 +0000 (11:19 -0700)]
[PR target/118248] Avoid bogus alloca call in RISC-V backend
This is Jakub's patch and Ian's testcase for the slightly vexing fault building
the D runtime with an s390x-x-riscv cross compiler.
The core issue is we're allocating a vector to hold temporary registers
unconditionally, including cases where the vector isn't needed because the loop
isn't going to iterate.
In the cases where the vector isn't needed the length is computed with an
expression (x / y) - 1 where x / y will be zero. The alloca(-1) on the s390
platform triggers a fault. We haven't seen the fault with an x86 cross, but we
can certainly see the bogus value being passed to alloca with a debugger.
Jakub patch just conditionalizes the whole block in a sensible way. So it
looks larger than it really is. I thought it might be better to do a bit of
manual CSE on this code to make it even more obvious, but I think we're
ultimately OK here.
Ian provided the testcase, collapsed down into equivalent C code. Again, it
doesn't fault on an x86-x-riscv, but I can see the incorrect behavior with a
debugger.
And a shout-out to Stefan for providing a docker based reproducer, it really
helped track this down.
PR target/118248
gcc/
* config/riscv/riscv-string.cc (riscv_block_move_straight): Only
allocate REGS buffer if it will be needed.
gcc/testsuite
* gcc.target/riscv/pr118248.c: New test.
Georg-Johann Lay [Fri, 14 Feb 2025 19:22:58 +0000 (20:22 +0100)]
AVR: Don't asm output operations for unused result bytes.
When REG_UNUSED notes indicate that some result bytes are not
used by the following code, then there's no need to asm out them.
The patch uses such notes for the asm out of AND, IOR, XOR, PLUS, MINUS.
gcc/
* config/avr/avr.cc (avr_result_regno_unused_p): New static function.
(avr_out_bitop): Only output result bytes that are used.
(avr_out_plus_1): Same.
Georg-Johann Lay [Sat, 15 Feb 2025 13:35:24 +0000 (14:35 +0100)]
AVR: Diagnose unsupported built-ins in avr_resolve_overloaded_builtin.
This patch executes avr_builtin_supported_p at a later time and in
avr_resolve_overloaded_builtin. This allows for better diagnostics
and avoids lto1 hiccups when a built-in decl is NULL_TREE.
Thomas Koenig [Sun, 16 Feb 2025 11:24:13 +0000 (12:24 +0100)]
Remove double output of attr->save.
In the recent patch for dumping all attributes, there were
duplicates for attr->save, which is output via gfc_code2string
previously. This patch removes that double output.
gcc/fortran/ChangeLog:
* dump-parse-tree.cc (show_attr): Remove double output
of attr->save.
H.J. Lu [Tue, 14 Mar 2023 18:41:51 +0000 (11:41 -0700)]
x86: Properly find the maximum stack slot alignment
Don't assume that stack slots can only be accessed by stack or frame
registers. We first find all registers defined by stack or frame
registers. Then check memory accesses by such registers, including
stack and frame registers.
gcc/
PR target/109780
PR target/109093
* config/i386/i386.cc (ix86_update_stack_alignment): New.
(ix86_find_all_reg_use_1): Likewise.
(ix86_find_all_reg_use): Likewise.
(ix86_find_max_used_stack_alignment): Also check memory accesses
from registers defined by stack or frame registers.
Jakub Jelinek [Sat, 15 Feb 2025 23:45:21 +0000 (16:45 -0700)]
[PR tree-optimization/98028] Use relationship between operands to simplify SUB_OVERFLOW
So this is a fairly old regression, but with all the ranger work that's been
done, it's become easy to resolve.
The basic idea here is to use known relationships between two operands of a
SUB_OVERFLOW IFN to statically compute the overflow state and ultimately allow
turning the IFN into simple arithmetic (or for the tests in this BZ elide the
arithmetic entirely).
The regression example is when the two inputs are known equal. In that case
the subtraction will never overflow. But there's a few other cases we can
handle as well.
a == b -> never overflows
a > b -> never overflows when A and B are unsigned
a >= b -> never overflows when A and B are unsigned
a < b -> always overflows when A and B are unsigned
Bootstrapped and regression tested on x86, and regression tested on the usual
cross platforms.
This is Jakub's version of the vr-values.cc fix rather than Jeff's.
PR tree-optimization/98028
gcc/
* vr-values.cc (check_for_binary_op_overflow): Try to use a known
relationship betwen op0/op1 to statically determine overflow state.
gcc/testsuite
* gcc.dg/tree-ssa/pr98028.c: New test.
Harald Anlauf [Sat, 15 Feb 2025 19:36:15 +0000 (20:36 +0100)]
Fortran: passing of derived type to VALUE,OPTIONAL dummy argument [PR118080]
For scalar OPTIONAL dummy arguments with the VALUE attribute, gfortran
passes a hidden flag to denote presence or absence of the actual argument
for intrinsic types. Extend this treatment to derived type (user-defined
as well as from intrinsic module ISO_C_BINDING).
PR fortran/118080
gcc/fortran/ChangeLog:
* gfortran.texi: Adjust documentation.
* trans-decl.cc (create_function_arglist): Adjust to pass hidden
presence flag also for derived type dummies with VALUE,OPTIONAL
attribute.
* trans-expr.cc (gfc_conv_expr_present): Expect hidden presence
flag also for derived type dummies with VALUE,OPTIONAL attribute.
(conv_cond_temp): Adjust to allow derived types.
(conv_dummy_value): Extend to handle derived type dummies with
VALUE,OPTIONAL attribute.
(gfc_conv_procedure_call): Adjust for actual arguments passed to
derived type dummies with VALUE,OPTIONAL attribute.
* trans-types.cc (gfc_get_function_type): Adjust fndecl for
hidden presence flag.
Jerry DeLisle [Fri, 14 Feb 2025 04:19:56 +0000 (20:19 -0800)]
Fortran: gfortran allows type(C_ptr) in I/O list
Before this patch, gfortran was accepting invalid use of
type(c_ptr) in I/O statements. The fix affects several
existing test cases so no new test case needed.
Existing tests were modified to pass by either using the
transfer function to convert to an acceptable value or
using an assignment to a like type (non-I/O).
PR fortran/117430
gcc/fortran/ChangeLog:
* resolve.cc (resolve_transfer): Change gfc_notify_std to
gfc_error.
gcc/testsuite/ChangeLog:
* gfortran.dg/c_loc_test_17.f90: Use an assignment rather than
PRINT.
* gfortran.dg/c_ptr_tests_10.f03: Use a transfer function.
* gfortran.dg/c_ptr_tests_16.f90: Use an assignment.
* gfortran.dg/c_ptr_tests_9.f03: Use a transfer function.
* gfortran.dg/init_flag_17.f90: Likewise.
* gfortran.dg/pr32601_1.f03: Use an assignment.
Robin Dapp [Sat, 15 Feb 2025 16:21:34 +0000 (09:21 -0700)]
[PATCH] RISC-V: Fix some widen-complicate tests.
this patch adds two bridge patterns for combine in order to fix the
widen-complicate tests that regressed since GCC 14.
They key is to allow combination with a ephemeral binary-operation insn
that widens its first operand. This can subsequently be combined two
a double-widening insn. If the combination doesn't happen we fall back
to the original non-combined two insns. We have been doing the same
thing for multiply-add patterns for a while.
There are still remaining tests of a similar kind that fail. The issue
there is indeed that combine (now) lacks the capability to continue in
cases where there is no apparent local progress but two or three
seemingly no-progress combinations would help us get a better "global" result.
late_combine cannot rescue us here either because it only performs a
propagation if the source can be propagated into all its uses which is
not the case here. What we might need to do is create internal functions
for those widening operations and combine/simplify at gimple-level already.
I have done testing on rv64gcv_zvl512b but on an older local commit.
Curious what the CI has to say about it now.
Regards
Robin
gcc/ChangeLog:
* config/riscv/autovec-opt.md
(*single_widen_first_<any_widen_binop:optab><any_extend:su><mode>):
New combine "bridge" pattern.
Keith Packard [Sat, 15 Feb 2025 16:17:41 +0000 (09:17 -0700)]
[PATCH] rx: allow cmpstrnsi len to be zero
The SCMPU instruction doesn't change the C and Z flags when the
incoming length is zero, which means the insn will produce a
value based upon the existing flag values.
As a quick kludge, adjust these flags to ensure a zero result in this
case.
David Malcolm [Sat, 15 Feb 2025 13:18:19 +0000 (08:18 -0500)]
sarif-replay: handle the 'fixes' property (§3.27.30)
This adds support to sarif-replay to display fix-it hints
stored in GCC's SARIF output.
gcc/ChangeLog:
* libsarifreplay.cc (sarif_replayer::handle_result_obj): Call
handle_fix_object if we see a single-element "fixes" array.
(sarif_replayer::handle_fix_object): New.
(sarif_replayer::handle_artifact_change_object): New.
gcc/testsuite/ChangeLog:
* sarif-replay.dg/2.1.0-valid/3.27.30-fixes-1.sarif: New test.
* sarif-replay.dg/2.1.0-valid/3.27.30-fixes-2.sarif: New test.
* sarif-replay.dg/2.1.0-valid/3.27.30-fixes-3.sarif: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
David Malcolm [Sat, 15 Feb 2025 13:15:58 +0000 (08:15 -0500)]
sarif-replay: handle relatedLocations without messages (§3.27.22)
Given the .sarif output from e.g.:
too-many-arguments.c: In function 'test_known_fn':
too-many-arguments.c:14:3: error: too many arguments to function 'fn_a'; expected 0, have 1
14 | fn_a (42);
| ^~~~ ~~
too-many-arguments.c:8:13: note: declared here
8 | extern void fn_a ();
| ^~~~
the underlining of the stray argument (the "42") is captured in
'relatedLocations' (§3.27.22) but previously sarif-replay would not
display this:
In function 'test_known_fn':
too-many-arguments.c:14:3: error: too many arguments to function 'fn_a'; expected 0, have 1 [error]
14 | fn_a (42);
| ^~~~
too-many-arguments.c:8:13: note: declared here
8 | extern void fn_a ();
| ^~~~
With this patch sarif-replay handles the relatedLocations element as
a secondary location in libgdiagnostics, and correctly underlines
the "42":
In function 'test_known_fn':
too-many-arguments.c:14:3: error: too many arguments to function 'fn_a'; expected 0, have 1 [error]
14 | fn_a (42);
| ^~~~ ~~
too-many-arguments.c:8:13: note: declared here
8 | extern void fn_a ();
| ^~~~
gcc/ChangeLog:
* libsarifreplay.cc (sarif_replayer::handle_result_obj): Treat any
relatedLocations without messages as secondary ranges within the
diagnostic. Doing so requires stashing the notes until after
the diagnostic has been finished, so that relatedLocations can be
walked in one pass.
gcc/testsuite/ChangeLog:
* sarif-replay.dg/2.1.0-valid/unlabelled-secondary-locations.sarif:
New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
David Malcolm [Sat, 15 Feb 2025 13:13:06 +0000 (08:13 -0500)]
sarif-replay: display annotations as labelled ranges (§3.28.6) [PR118881]
In our .sarif output from e.g.:
bad-binary-op.c: In function ‘test_4’:
bad-binary-op.c:19:23: error: invalid operands to binary + (have ‘S’ {aka ‘struct s’} and ‘T’ {aka ‘struct t’})
19 | return callee_4a () + callee_4b ();
| ~~~~~~~~~~~~ ^ ~~~~~~~~~~~~
| | |
| | T {aka struct t}
| S {aka struct s}
the labelled ranges are captured in the 'annotations' property of the
'location' object (§3.28.6).
However sarif-replay emits just:
In function 'test_4':
bad-binary-op.c:19:23: error: invalid operands to binary + (have ‘S’ {aka ‘struct s’} and ‘T’ {aka ‘struct t’}) [error]
19 | return callee_4a () + callee_4b ();
| ^
missing the labelled ranges.
This patch adds support to sarif-replay for the 'annotations' property;
with this patch we emit:
In function 'test_4':
bad-binary-op.c:19:23: error: invalid operands to binary + (have ‘S’ {aka ‘struct s’} and ‘T’ {aka ‘struct t’}) [error]
19 | return callee_4a () + callee_4b ();
| ~~~~~~~~~~~~ ^ ~~~~~~~~~~~~
| | |
| | T {aka struct t}
| S {aka struct s}
thus showing the labelled ranges.
Doing so requires adding a new entrypoint to libgdiagnostics:
diagnostic_physical_location_get_file
Given that we haven't yet released a stable version and that
sarif-replay is built together with libgdiagnostics I didn't
bother updating the ABI version.
gcc/ChangeLog:
PR sarif-replay/118881
* doc/libgdiagnostics/topics/physical-locations.rst: Add
diagnostic_physical_location_get_file.
* libgdiagnostics++.h (physical_location::get_file): New wrapper.
(diagnostic::add_location): Likewise.
* libgdiagnostics.cc (diagnostic_manager::get_file_by_name): New.
(diagnostic_physical_location::get_file): New.
(diagnostic_physical_location_get_file): New.
* libgdiagnostics.h (diagnostic_physical_location_get_file): New.
* libgdiagnostics.map (diagnostic_physical_location_get_file): New.
* libsarifreplay.cc (class annotation): New.
(add_any_annotations): New.
(sarif_replayer::handle_result_obj): Collect vectors of
annotations in the calls to handle_location_object and apply them
to "err" and to "note" as appropriate.
(sarif_replayer::handle_thread_flow_location_object): Pass nullptr
for annotations.
(sarif_replayer::handle_location_object): Handle §3.28.6
"annotations" property, using it to populate a new
"out_annotations" param.
gcc/testsuite/ChangeLog:
PR sarif-replay/118881
* sarif-replay.dg/2.1.0-valid/3.28.6-annotations-1.sarif: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
Nathaniel Shead [Wed, 12 Feb 2025 08:15:22 +0000 (19:15 +1100)]
c++/modules: Don't treat template parameters as TU-local [PR118846]
There are two separate issues making various template parameters behave
as if they were TU-local.
Firstly, the TU-local detection code uses WILDCARD_TYPE_P to check for
types that are not yet concrete; for some reason UNBOUND_CLASS_TEMPLATE
is not on that list. I don't see any particular reason why it shouldn't
be, so this patch adds it; this may solve other latent issues as well.
Secondly, the TEMPLATE_DECL for a type with expressions involving
TEMPLATE_TEMPLATE_PARM_Ps is currently always constrained to internal
linkage, because the result does not have TREE_PUBLIC set. Rather than
messing with TREE_PUBLIC here, I think rather we just should ensure that
we only attempt to constrain visiblity of templates of type, variable,
or function decls.
PR c++/118846
gcc/cp/ChangeLog:
* cp-tree.h (WILDCARD_TYPE_P): Include UNBOUND_CLASS_TEMPLATE.
* decl2.cc (min_vis_expr_r): Don't assume a TEMPLATE_DECL will
be a function or variable.
gcc/testsuite/ChangeLog:
* g++.dg/modules/pr118846_a.C: New test.
* g++.dg/modules/pr118846_b.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com> Reviewed-by: Jason Merrill <jason@redhat.com>
Jason Merrill [Sat, 15 Feb 2025 09:48:17 +0000 (10:48 +0100)]
c++: NRVO, constexpr, lambda [PR118053]
Here during constant evaluation we encounter a VAR_DECL with DECL_VALUE_EXPR
of the RESULT_DECL, where the latter has been adjusted for
pass-by-invisible-reference. We already had the code to deal with this, we
just need to use it in the non-capture case of DECL_VALUE_EXPR as well.
PR c++/118053
gcc/cp/ChangeLog:
* constexpr.cc (cxx_eval_constant_expression): Generalize
DECL_VALUE_EXPR invisiref handling.
Jonathan Wakely [Thu, 13 Feb 2025 00:26:27 +0000 (00:26 +0000)]
libstdc++: Simplify and comment std::jthread extension [PR100612]
Use a requires-clause on the partial specialization of the
__pmf_expects_stop_token variable template, which is used for the
extension that allows constructing std::jthread with a
pointer-to-member-function that accepts a std::stop_token argument.
Also add a comment referring to the related Bugzilla PR.
Jonathan Wakely [Wed, 12 Feb 2025 19:43:05 +0000 (19:43 +0000)]
libstdc++: Add conditional noexcept to remaining range access functions
Add conditional noexcept to the remaining range access functions that
were not changed in r15-5669-g8692cb10e82e72. This is now being proposed
for C++26 by P3623R0 (not published yet).
libstdc++-v3/ChangeLog:
* include/bits/range_access.h (rbegin, rend, crbegin, crend):
Add conditional noexcept, as per P3623R0.
* testsuite/24_iterators/headers/iterator/range_access.cc: Add
noexcept-specifier to rbegin, rend, crbegin and crend
declarations.
Jonathan Wakely [Wed, 12 Feb 2025 19:52:01 +0000 (19:52 +0000)]
libstdc++: Combine three tests into one
Instead of a test with { target c++11_only } and another with
c++14_only and another with c++17 we can have a single test that uses
{ target c++11 }. This avoids needing to make edits to three very
similar tests.
Also fix the signatures for std::cbegin and std::cend which had the
wrong expression in the trailing-return-type and were missing their
constexpr and conditional noexcept (which were always present even in
C++14). That was wrong in two files, but now only needs to be fixed in
one place!
Thomas Koenig [Sat, 15 Feb 2025 10:38:05 +0000 (11:38 +0100)]
Fix PR 118884, Lapack build failure.
The fix for PR 118845 introduced new checks, which in turn exposed
a case where the typespec information on a symbol generated symbol
was not set. This led to an apparent type of BT_UNKNOWN, and hence
an error. Fixed as obvoius and simple.
gcc/fortran/ChangeLog:
* frontend-passes.cc (check_externals_procedure): Copy
typespec from old to new symbol.
Thomas Schwinge [Mon, 19 Dec 2022 14:05:53 +0000 (15:05 +0100)]
nvptx: Tag 'gcc/config/nvptx/nvptx.cc:nvptx_record_needed_fndecl' as 'static'
As of Subversion r231013 (Git commit 00e5241831c1227615a45b7bcba29c393671cb3f)
"[PTX] Another libcall patch", only used 'nvptx_record_needed_fndecl' is
locally.
gcc/
* config/nvptx/nvptx.cc (nvptx_record_needed_fndecl): Tag as
'static'.
Andrew Pinski [Thu, 13 Feb 2025 22:10:06 +0000 (14:10 -0800)]
libstdc++: Improve list assumption after constructor [PR118865]
The code example here does:
```
if (begin == end) __builtin_unreachable();
std::list nl(begin, end);
for (auto it = nl.begin(); it != nl.end(); it++)
{
...
}
/* Remove the first element of the list. */
nl.erase(nl.begin());
```
And we get a warning because because we jump threaded the case were we
think the list was empty from the for loop BUT we populated it without
an empty array. So can help the compiler here by adding that after initializing
the list with non empty array, that the list will not be empty either.
This is able to remove the -Wfree-nonheap-object warning in the first reduced
testcase (with the fix for `begin == end` case added) in the PR 118865; the second
reduced testcase has been filed off as PR 118867.
Bootstrapped and tested on x86_64-linux-gnu.
libstdc++-v3/ChangeLog:
PR libstdc++/118865
* include/bits/stl_list.h (_M_initialize_dispatch): Add an
unreachable if the iterator was not empty that the list will
now be not empty.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
Georg-Johann Lay [Fri, 14 Feb 2025 17:53:29 +0000 (18:53 +0100)]
AVR: target/118878 - Don't ICE on result from paradoxical reg's alloc.
After register allocation, paradoxical subregs may become something
like r20:SI += r22:SI which doesn't make much sense as assembly code.
Hence avr_out_plus_1() used to ICE on such code. However, paradoxical
subregs appear to be a common optimization device (instead of proper
mode demotion).
PR target/118878
gcc/
* config/avr/avr.cc (avr_out_plus_1): Don't ICE on result of
paradoxical reg's register allocation.
gcc/testsuite/
* gcc.target/avr/torture/pr118878.c: New test.
Thomas Schwinge [Tue, 11 Feb 2025 16:23:28 +0000 (17:23 +0100)]
GCN: Set 'UI_TARGET' for 'TARGET_EXCEPT_UNWIND_INFO' [PR94282, PR113331]
In commit 7f1989249e25af6fc0f124452efa24b3796b767a
"[gcn] Set 'UI_NONE' for 'TARGET_EXCEPT_UNWIND_INFO' [PR94282]", we've copied
the 'UI_NONE' idea from nvptx to GCN.
I understand the intention of using 'UI_NONE' like this, and it happens to work
in a lot of cases, but there are ICEs elsewhere: code paths where we run into
'internal compiler error: in get_personality_function, at expr.cc:13512':
13494 /* Extracts the personality function of DECL and returns the corresponding
13495 libfunc. */
13496
13497 rtx
13498 get_personality_function (tree decl)
13499 {
13500 tree personality = DECL_FUNCTION_PERSONALITY (decl);
13501 enum eh_personality_kind pk;
13502
13503 pk = function_needs_eh_personality (DECL_STRUCT_FUNCTION (decl));
13504 if (pk == eh_personality_none)
13505 return NULL;
13506
13507 if (!personality
13508 && pk == eh_personality_any)
13509 personality = lang_hooks.eh_personality ();
13510
13511 if (pk == eh_personality_lang)
13512 gcc_assert (personality != NULL_TREE);
13513
13514 return XEXP (DECL_RTL (personality), 0);
13515 }
..., where 'lang_hooks.eh_personality ()' ends up calling
'gcc/expr.cc:build_personality_function', and we 'return NULL;' for 'UI_NONE':
13448 /* Build a decl for a personality function given a language prefix. */
13449
13450 tree
13451 build_personality_function (const char *lang)
13452 {
13453 const char *unwind_and_version;
13454 tree decl, type;
13455 char *name;
13456
13457 switch (targetm_common.except_unwind_info (&global_options))
13458 {
13459 case UI_NONE:
13460 return NULL;
[...]
(Comparing to nvptx' current use of 'UI_NONE', this problem (ICEs mentioned
above) is way more prevalent for GCN.)
The GCC internals documentation indeed states, 'gcc/doc/tm.texi':
@deftypefn {Common Target Hook} {enum unwind_info_type} TARGET_EXCEPT_UNWIND_INFO (struct gcc_options *@var{opts})
This hook defines the mechanism that will be used for exception handling
by the target. If the target has ABI specified unwind tables, the hook
should return @code{UI_TARGET}. If the target is to use the
@code{setjmp}/@code{longjmp}-based exception handling scheme, the hook
should return @code{UI_SJLJ}. If the target supports DWARF 2 frame unwind
information, the hook should return @code{UI_DWARF2}.
A target may, if exceptions are disabled, choose to return @code{UI_NONE}.
This may end up simplifying other parts of target-specific code. [...]
Here, note: "if exceptions are disabled" (meaning: '-fno-exceptions' etc.) may
"return @code{UI_NONE}". That's what other back ends do with code like:
/* For simplicity elsewhere in this file, indicate that all unwind
info is disabled if we're not emitting unwind tables. */
if (!opts->x_flag_exceptions && !opts->x_flag_unwind_tables)
return UI_NONE;
else
return UI_TARGET;
The corresponding "simplifying other parts of target-specific code"/
"simplicity elsewhere" would then be the early returns from
'TARGET_ASM_UNWIND_EMIT', 'ARM_OUTPUT_FN_UNWIND', etc. for
'TARGET_EXCEPT_UNWIND_INFO != UI_TARGET' (that is, for 'UI_NONE').
From the documentation (and implementation), however, it does *not* follow that
if a target doesn't implement support for exception handling, it may just set
'UI_NONE' for 'TARGET_EXCEPT_UNWIND_INFO'.
Therefore, switch to 'UI_TARGET', allocating a "fake" 'exception_section'.
With that, all these 'internal compiler error: in get_personality_function'
test cases turn into PASS, or UNSUPPORTED ('exception handling not supported'),
or re-classify into a few other, already known issues. And, this change also
happens to resolve the class of errors identified in GCC PR113331
"AMDGCN: Compilation failure due to duplicate .LEHB<n>/.LEHE<n> symbols".
(In case that use of 'UI_NONE' like originally intended really makes sense, and
is preferable over this 'UI_TARGET' solution, then more work will be necessary
for implementing the missing parts, where 'UI_NONE' currently isn't handled.)
I understand the intention of using 'UI_NONE' like this, and it happens to work
in a lot of cases, but there are ICEs elsewhere: code paths where we run into
'internal compiler error: in get_personality_function, at expr.cc:13512':
13494 /* Extracts the personality function of DECL and returns the corresponding
13495 libfunc. */
13496
13497 rtx
13498 get_personality_function (tree decl)
13499 {
13500 tree personality = DECL_FUNCTION_PERSONALITY (decl);
13501 enum eh_personality_kind pk;
13502
13503 pk = function_needs_eh_personality (DECL_STRUCT_FUNCTION (decl));
13504 if (pk == eh_personality_none)
13505 return NULL;
13506
13507 if (!personality
13508 && pk == eh_personality_any)
13509 personality = lang_hooks.eh_personality ();
13510
13511 if (pk == eh_personality_lang)
13512 gcc_assert (personality != NULL_TREE);
13513
13514 return XEXP (DECL_RTL (personality), 0);
13515 }
..., where 'lang_hooks.eh_personality ()' ends up calling
'gcc/expr.cc:build_personality_function', and we 'return NULL;' for 'UI_NONE':
13448 /* Build a decl for a personality function given a language prefix. */
13449
13450 tree
13451 build_personality_function (const char *lang)
13452 {
13453 const char *unwind_and_version;
13454 tree decl, type;
13455 char *name;
13456
13457 switch (targetm_common.except_unwind_info (&global_options))
13458 {
13459 case UI_NONE:
13460 return NULL;
[...]
(Comparing to nvptx' current use of 'UI_NONE', this problem (ICEs mentioned
above) is way more prevalent for GCN.)
The GCC internals documentation indeed states, 'gcc/doc/tm.texi':
@deftypefn {Common Target Hook} {enum unwind_info_type} TARGET_EXCEPT_UNWIND_INFO (struct gcc_options *@var{opts})
This hook defines the mechanism that will be used for exception handling
by the target. If the target has ABI specified unwind tables, the hook
should return @code{UI_TARGET}. If the target is to use the
@code{setjmp}/@code{longjmp}-based exception handling scheme, the hook
should return @code{UI_SJLJ}. If the target supports DWARF 2 frame unwind
information, the hook should return @code{UI_DWARF2}.
A target may, if exceptions are disabled, choose to return @code{UI_NONE}.
This may end up simplifying other parts of target-specific code. [...]
Here, note: "if exceptions are disabled" (meaning: '-fno-exceptions' etc.) may
"return @code{UI_NONE}". That's what other back ends do with code like:
/* For simplicity elsewhere in this file, indicate that all unwind
info is disabled if we're not emitting unwind tables. */
if (!opts->x_flag_exceptions && !opts->x_flag_unwind_tables)
return UI_NONE;
else
return UI_TARGET;
The corresponding "simplifying other parts of target-specific code"/
"simplicity elsewhere" would then be the early returns from
'TARGET_ASM_UNWIND_EMIT', 'ARM_OUTPUT_FN_UNWIND', etc. for
'TARGET_EXCEPT_UNWIND_INFO != UI_TARGET' (that is, for 'UI_NONE').
From the documentation (and implementation), however, it does *not* follow that
if a target doesn't implement support for exception handling, it may just set
'UI_NONE' for 'TARGET_EXCEPT_UNWIND_INFO'.
Therefore, switch (back) to 'UI_TARGET', implementing some basic support for
'exception_section': discard (via a PTX comment block) whatever GCC writes into
it.
With that, all these 'internal compiler error: in get_personality_function'
test cases turn into PASS, or UNSUPPORTED ('exception handling not supported'),
or re-classify into a few other, already known issues.
(In case that use of 'UI_NONE' like originally intended really makes sense, and
is preferable over this 'UI_TARGET' solution, then more work will be necessary
for implementing the missing parts, where 'UI_NONE' currently isn't handled.)
Thomas Schwinge [Wed, 12 Feb 2025 23:35:31 +0000 (00:35 +0100)]
nvptx: Sanity-check 'init_frag' state
The 'init_frag' machinery is used by 'nvptx_assemble_integer' (via
'TARGET_ASM_INTEGER'), 'nvptx_output_skip' (via 'ASM_OUTPUT_SKIP'),
'nvptx_output_ascii' (via 'ASM_OUTPUT_ASCII'). But, it's not obvious that
these are called only when that machinery is active (and in a consistent
state), which it only is in 'nvptx_output_aligned_decl' (via
'ASM_OUTPUT_ALIGNED_DECL_COMMON', or 'ASM_OUTPUT_ALIGNED_DECL_LOCAL'), or in
'nvptx_assemble_undefined_decl' (via 'TARGET_ASM_ASSEMBLE_UNDEFINED_DECL'), or
within a region started by 'nvptx_assemble_decl_begin' (via
'nvptx_asm_declare_constant_name' (via 'TARGET_ASM_DECLARE_CONSTANT_NAME'), or
via 'nvptx_declare_object_name' (via 'ASM_DECLARE_OBJECT_NAME')) and ended by
'nvptx_assemble_decl_end' (via 'TARGET_ASM_DECL_END').
And indeed, in a GCC/nvptx offloading configuration, we then find that
'nvptx_output_skip' (via 'ASM_OUTPUT_SKIP') is getting called in inconsistent
'init_frag' state, in 'gcc/varasm.cc', via 'assemble_zeros', from
'output_object_block', to "Move to the object's offset, padding with zeros".
Supposedly, this didn't cause any damage, but we now handle it explicitly.
(..., and the question remains whether such "padding" etc. shouldn't actually
be attempted for targets like nvptx.)
gcc/
* config/nvptx/nvptx.cc (init_frag): New 'bool active' member.
(output_init_frag, nvptx_assemble_value, nvptx_assemble_integer)
(nvptx_output_skip, nvptx_assemble_decl_begin)
(nvptx_assemble_decl_end): Sanity-check its state.
Richard Biener [Fri, 14 Feb 2025 13:48:41 +0000 (14:48 +0100)]
tree-optimization/118852 - wrong code with 502.gcc_r
502.gcc_r when built with -fprofile-generate exposes a SLP discovery
issue where an IV forced live due to early break is not properly
discovered if its latch def is part of a different IVs SSA cycle.
To mitigate this we have to make sure to create an SLP instance
for the original IV. Ideally we'd handle all vect_induction_def
the same but this is left for next stage1.
PR tree-optimization/118852
* tree-vect-slp.cc (vect_analyze_slp): For early-break
forced-live IVs make sure we create an appropriate
entry into the SLP graph.
projects / thirdparty / gcc.git / log
