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>
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>
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>
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 GIMPLE pass: vect
pr116351-1.c: In function ‘i’:
pr116351-1.c:8:6: internal compiler error: in get_len_load_store_mode,
at optabs-tree.cc:655
8 | void i () {
| ^
0x44d6b9d internal_error(char const*, ...)
/home/pli/gcc/111/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/diagnostic-global-context.cc:517
0x44a26a6 fancy_abort(char const*, int, char const*)
/home/pli/gcc/111/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/diagnostic.cc:1722
0x19e4309 get_len_load_store_mode(machine_mode, bool, internal_fn*, vec<int, va_heap, vl_ptr>*)
/home/pli/gcc/111/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/optabs-tree.cc:655
0x1fada40 vect_verify_loop_lens
/home/pli/gcc/111/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/tree-vect-loop.cc:1566
0x1fb2b07 vect_analyze_loop_2
/home/pli/gcc/111/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/tree-vect-loop.cc:3037
0x1fb4302 vect_analyze_loop_1
/home/pli/gcc/111/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/tree-vect-loop.cc:3478
0x1fb4e9a vect_analyze_loop(loop*, gimple*, vec_info_shared*)
/home/pli/gcc/111/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/tree-vect-loop.cc:3638
0x203c2dc try_vectorize_loop_1
/home/pli/gcc/111/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/tree-vectorizer.cc:1095
0x203c839 try_vectorize_loop
/home/pli/gcc/111/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/tree-vectorizer.cc:1212
0x203cb2c execute
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.
Signed-off-by: Pan Li <pan2.li@intel.com>
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:
- gcc.dg/vect/vect-reduc-chain-2.c
- gcc.dg/vect/vect-reduc-chain-3.c
- gcc.dg/vect/vect-reduc-chain-dot-slp-3.c
- gcc.dg/vect/vect-reduc-chain-dot-slp-4.c
gcc/ChangeLog:
* config/loongarch/simd.md (wvec_half): New define_mode_attr.
(<su>dot_prod<wvec_half><mode>): New define_expand.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/wide-mul-reduc-2.c (dg-final): Scan
DOT_PROD_EXPR in optimized tree.
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.
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.
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.
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.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/vrepli.c: New test.
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.
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.
The file-cache-lines / file-cache-files tunables were documented in the
wrong section. Fix that.
Reported-by: Filip Kastl
Comitted as obvious.
gcc/ChangeLog:
* doc/invoke.texi:
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>
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>
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.
Signed-off-by: Roman Kagan <rkagan@amazon.de>
In PR115703 we fuse two vsetvls:
Fuse curr info since prev info compatible with it:
prev_info: VALID (insn 438, bb 2)
Demand fields: demand_ge_sew demand_non_zero_avl
SEW=32, VLMUL=m1, RATIO=32, MAX_SEW=64
TAIL_POLICY=agnostic, MASK_POLICY=agnostic
AVL=(reg:DI 0 zero)
VL=(reg:DI 9 s1 [312])
curr_info: VALID (insn 92, bb 20)
Demand fields: demand_ratio_and_ge_sew demand_avl
SEW=64, VLMUL=m1, RATIO=64, MAX_SEW=64
TAIL_POLICY=agnostic, MASK_POLICY=agnostic
AVL=(const_int 4 [0x4])
VL=(nil)
prev_info after fused: VALID (insn 438, bb 2)
Demand fields: demand_ratio_and_ge_sew demand_avl
SEW=64, VLMUL=mf2, RATIO=64, MAX_SEW=64
TAIL_POLICY=agnostic, MASK_POLICY=agnostic
AVL=(const_int 4 [0x4])
VL=(nil).
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.
When use_gcc_stdint=provide, the stdint-gcc.h header is not provided.
2025-02-18 John David Anglin <danglin@gcc.gnu.org>
gcc/testsuite/ChangeLog:
PR testsuite/116986
* gcc.dg/crc-builtin-rev-target32.c: Include stdint.h
instead of stdint-gcc.h.
* gcc.dg/crc-builtin-rev-target64.c: Likewise.
* gcc.dg/crc-builtin-target32.c: Likewise.
* gcc.dg/crc-builtin-target64.c: Likewise.
* gcc.dg/torture/pr115387-2.c: Likewise.
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.
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.
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.
generic_armv8_a.h defines generic_armv8_a_prefetch_tune but still uses
generic_prefetch_tune in generic_armv8_a_tunings.
This patch updates the pointer to generic_armv8_a_prefetch_tune.
This patch was bootstrapped and regtested on aarch64-linux-gnu, no regression.
Signed-off-by: Soumya AR <soumyaa@nvidia.com>
gcc/ChangeLog:
* config/aarch64/tuning_models/generic_armv8_a.h: Updated prefetch
struct pointer.
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.
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
during RTL pass: fwprop1
test.c: In function ‘foo’:
test.c:10:1: internal compiler error: in add_use, at
rtl-ssa/accesses.cc:1234
10 | }
| ^
0x44d6b9d internal_error(char const*, ...)
/home/pli/gcc/111/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/diagnostic-global-context.cc:517
0x44a26a6 fancy_abort(char const*, int, char const*)
/home/pli/gcc/111/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/diagnostic.cc:1722
0x408fac9 rtl_ssa::function_info::add_use(rtl_ssa::use_info*)
/home/pli/gcc/111/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/rtl-ssa/accesses.cc:1234
0x40a5eea
rtl_ssa::function_info::create_reg_use(rtl_ssa::function_info::build_info&,
rtl_ssa::insn_info*, rtl_ssa::resource_info)
/home/pli/gcc/111/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/rtl-ssa/insns.cc:496
0x4456738
rtl_ssa::function_info::add_artificial_accesses(rtl_ssa::function_info::build_info&,
df_ref_flags)
/home/pli/gcc/111/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/rtl-ssa/blocks.cc:900
0x4457297
rtl_ssa::function_info::start_block(rtl_ssa::function_info::build_info&,
rtl_ssa::bb_info*)
/home/pli/gcc/111/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/rtl-ssa/blocks.cc:1082
0x4453627
rtl_ssa::function_info::bb_walker::before_dom_children(basic_block_def*)
/home/pli/gcc/111/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/rtl-ssa/blocks.cc:118
0x3e9f3fb dom_walker::walk(basic_block_def*)
/home/pli/gcc/111/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/domwalk.cc:311
0x445806f rtl_ssa::function_info::process_all_blocks()
/home/pli/gcc/111/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/rtl-ssa/blocks.cc:1298
0x40a22d3 rtl_ssa::function_info::function_info(function*)
/home/pli/gcc/111/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/rtl-ssa/functions.cc:51
0x3ec3f80 fwprop_init
/home/pli/gcc/111/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/fwprop.cc:893
0x3ec420d fwprop
/home/pli/gcc/111/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/fwprop.cc:963
0x3ec43ad execute
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.
Signed-off-by: Pan Li <pan2.li@intel.com>
The order of i386.opt.urls need to be the same as i386.opt.
gcc/ChangeLog:
* config/i386/i386.opt.urls: Adjust the order for avx10.2
and avx10.2-512 due to their order change in i386.opt.
The existing usage comment for check-function-bodies is presumably a
typo, as it doesn't match existing uses. Fix it.
for gcc/testsuite/ChangeLog
* lib/scanasm.exp (check-function-bodies): Fix usage comment.
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.
for gcc/testsuite/ChangeLog
PR tree-optimization/118805
* gcc.dg/field-merge-26.c: New.
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.
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.
Constant integers with MSB set have to be represented as corresponding
signed integers. Use gen_int_mode to emit them in the correct way.
PR middle-end/118288
gcc/ChangeLog:
* builtins.cc (expand_builtin_crc_table_based):
Use gen_int_mode to emit constant integers with MSB set.
gcc/testsuite/ChangeLog:
* gcc.dg/pr118288.c: New test.
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.
gcc/testsuite/ChangeLog:
* g++.dg/ext/stmtexpr29.C: New test.
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.
* gcc.dg/pr118895.c: New testcase.
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>
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.
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.
gcc/ChangeLog:
* common/config/i386/i386-common.cc
(OPTION_MASK_ISA2_AVX2_UNSET): Change AVX10.1 unset macro.
(OPTION_MASK_ISA2_AVX10_1_256_UNSET): Removed.
(OPTION_MASK_ISA2_AVX10_1_512_UNSET): Removed.
(OPTION_MASK_ISA2_AVX10_1_UNSET): New.
(ix86_handle_option): Adjust AVX10.1 unset macro.
* common/config/i386/i386-isas.h: Remove avx10.1.
* config/i386/i386-options.cc
(ix86_valid_target_attribute_inner_p): Ditto.
(ix86_option_override_internal): Adjust warning message.
* config/i386/i386.opt: Remove mavx10.1.
* doc/extend.texi: Remove avx10.1 and adjust doc.
* doc/sourcebuild.texi: Ditto.
gcc/testsuite/ChangeLog:
* gcc.target/i386/avx10-check.h: Change to avx10.1-256.
* gcc.target/i386/avx10_1-1.c: Ditto.
* gcc.target/i386/avx10_1-13.c: Ditto.
* gcc.target/i386/avx10_1-14.c: Ditto.
* gcc.target/i386/avx10_1-21.c: Ditto.
* gcc.target/i386/avx10_1-22.c: Ditto.
* gcc.target/i386/avx10_1-23.c: Ditto.
* gcc.target/i386/avx10_1-24.c: Ditto.
* gcc.target/i386/avx10_1-3.c: Ditto.
* gcc.target/i386/avx10_1-5.c: Ditto.
* gcc.target/i386/avx10_1-6.c: Ditto.
* gcc.target/i386/avx10_1-8.c: Ditto.
* gcc.target/i386/pr117946.c: Ditto.
* gcc.target/i386/avx10_1-12.c: Adjust warning message.
* gcc.target/i386/avx10_1-19.c: Ditto.
* gcc.target/i386/avx10_1-17.c: Adjust to no-avx10.1-512.
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.
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).
The linking order:
lld: crtbeginS.o + .text + .plt
ld : .plt + crtbeginS.o + .text
To solve this issue, add '-mcmodel=extreme' when compiling crtbeginS.o.
PR target/118844
libgcc/ChangeLog:
* config/loongarch/t-crtstuff: Add '-mcmodel=extreme'
to CRTSTUFF_T_CFLAGS_S.
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.
