aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-09-14LoongArch: Add testsuite framework for Loongson SX/ASX.Xiaolong Chen2-0/+96
gcc/testsuite/ChangeLog: * gcc.target/loongarch/vector/loongarch-vector.exp: New test. * gcc.target/loongarch/vector/simd_correctness_check.h: New test.
2023-09-14LoongArch: Add tests of -mstrict-align option.Xiaolong Chen1-0/+12
gcc/testsuite/ChangeLog: * gcc.target/loongarch/strict-align.c: New test.
2023-09-14Daily bump.GCC Administrator6-1/+175
2023-09-13libstdc++: [_GLIBCXX_INLINE_VERSION] Fix <format> friend declarationFrançois Dumont1-1/+7
GCC do not consider the inline namespace in friend function declarations. This is PR c++/59526, we need to explicit this namespace. libstdc++-v3/ChangeLog: * include/std/format (std::__format::_Arg_store): Explicit version namespace on make_format_args friend declaration.
2023-09-13modula2: -Wcase-enum detect singular/plural and use switch during buildGaius Mulley11-23/+50
This patch generates a singular or plural message relating to the number of enums missing. Use -Wcase-enum when building of the modula-2 libraries and m2/stage2/cc1gm2. gcc/m2/ChangeLog: * Make-lang.in (GM2_FLAGS): Add -Wcase-enum. (GM2_ISO_FLAGS): Add -Wcase-enum. * gm2-compiler/M2CaseList.mod (EnumerateErrors): Issue singular or plural start text prior to the enum list. Remove unused parameter tokenno. (EmitMissingRangeErrors): New procedure. (MissingCaseBounds): Call EmitMissingRangeErrors. (MissingCaseStatementBounds): Call EmitMissingRangeErrors. * gm2-libs-iso/TextIO.mod: Fix spacing. libgm2/ChangeLog: * libm2cor/Makefile.am (libm2cor_la_M2FLAGS): Add -Wcase-enum. * libm2cor/Makefile.in: Regenerate. * libm2iso/Makefile.am (libm2iso_la_M2FLAGS): Add -Wcase-enum. * libm2iso/Makefile.in: Regenerate. * libm2log/Makefile.am (libm2log_la_M2FLAGS): Add -Wcase-enum. * libm2log/Makefile.in: Regenerate. * libm2pim/Makefile.am (libm2pim_la_M2FLAGS): Add -Wcase-enum. * libm2pim/Makefile.in: Regenerate. Signed-off-by: Gaius Mulley <gaiusmod2@gmail.com>
2023-09-13RISC-V: Support VLS modes VEC_EXTRACT auto-vectorizationJuzhe-Zhong5-9/+307
This patch support VLS modes VEC_EXTRACT to fix PR111391: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111391 I need VLS modes VEC_EXTRACT to fix this issue. I have run the whole gcc testsuite, notice this patch increase these 4 FAILs: FAIL: c-c++-common/vector-subscript-4.c -std=gnu++14 scan-tree-dump-not optimized "vector" FAIL: c-c++-common/vector-subscript-4.c -std=gnu++17 scan-tree-dump-not optimized "vector" FAIL: c-c++-common/vector-subscript-4.c -std=gnu++20 scan-tree-dump-not optimized "vector" FAIL: c-c++-common/vector-subscript-4.c -std=gnu++98 scan-tree-dump-not optimized "vector" After analysis and comparing with LLVM: https://godbolt.org/z/ozhfKhj5Y with this patch, GCC generate similar codegen like LLVM (Previously it can not be vectorized). This patch is the prerequisite patch to fix an ICE. So let's ignore those increased 4 dump IR FAILs since ICE is un-acceptable wheras dump FAILs are acceptable (But we should remember and eventually fix dump IR FAILs too). gcc/ChangeLog: * config/riscv/autovec.md (vec_extract<mode><vel>): Add VLS modes. (@vec_extract<mode><vel>): Ditto. * config/riscv/vector.md: Ditto gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/vls/def.h: Add more def. * gcc.target/riscv/rvv/autovec/vls/extract-1.c: New test. * gcc.target/riscv/rvv/autovec/vls/extract-2.c: New test.
2023-09-13MATCH: Move `X <= MAX(X, Y)` before `MIN (X, C1) < C2` patternAndrew Pinski1-7/+8
Since matching C1 as C2 here will decrease how much other simplifications will need to happen to get the final answer. OK? Bootstrapped and tested on x86_64-linux-gnu. gcc/ChangeLog: * match.pd (`X <= MAX(X, Y)`): Move before `MIN (X, C1) < C2` pattern.
2023-09-13MATCH: [PR111364] Add some more minmax cmp operand simplificationsAndrew Pinski5-5/+89
This adds a few more minmax cmp operand simplifications which were missed before. `MIN(a,b) < a` -> `a > b` `MIN(a,b) >= a` -> `a <= b` `MAX(a,b) > a` -> `a < b` `MAX(a,b) <= a` -> `a >= b` OK? Bootstrapped and tested on x86_64-linux-gnu. Note gcc.dg/pr96708-negative.c needed to updated to remove the check for MIN/MAX as they have been optimized (correctly) away. PR tree-optimization/111364 gcc/ChangeLog: * match.pd (`MIN (X, Y) == X`): Extend to min/lt, min/ge, max/gt, max/le. gcc/testsuite/ChangeLog: * gcc.c-torture/execute/minmaxcmp-1.c: New test. * gcc.dg/tree-ssa/minmaxcmp-2.c: New test. * gcc.dg/pr96708-negative.c: Update testcase. * gcc.dg/pr96708-positive.c: Add comment about `return 0`.
2023-09-13MATCH: Simplify `(X % Y) < Y` pattern.Andrew Pinski1-6/+1
This merges the two patterns to catch `(X % Y) < Y` and `Y > (X % Y)` into one by using :c on the comparison operator. It does not change any code generation nor anything else. It is more to allow for better maintainability of this pattern. OK? Bootstrapped and tested on x86_64-linux-gnu. gcc/ChangeLog: PR tree-optimization/111345 * match.pd (`Y > (X % Y)`): Merge into ... (`(X % Y) < Y`): Pattern by adding `:c` on the comparison.
2023-09-13tree-optimization/111387 - BB SLP and irreducible regionsRichard Biener2-4/+46
When we split an irreducible region for BB vectorization analysis the defensive handling of external backedge defs in vect_get_and_check_slp_defs doesn't work since that relies on dominance info to identify a backedge. The testcase also shows we are iterating over the function in a sub-optimal way which is why we split the irreducible region in the first place. The fix is to mark backedges and use EDGE_DFS_BACK to identify them and to use the region RPO compute which can produce a RPO order keeping cycles in a better order (and as side effect marks backedges). PR tree-optimization/111387 * tree-vect-slp.cc (vect_get_and_check_slp_defs): Check EDGE_DFS_BACK when doing BB vectorization. (vect_slp_function): Use rev_post_order_and_mark_dfs_back_seme to compute RPO and mark backedges. * gcc.dg/torture/pr111387.c: New testcase.
2023-09-13RISC-V: Support cond vmulh.vv and vmulu.vv autovec patternsLehua Ding7-20/+154
This patch adds combine patterns to combine vmulh[u].vv + vcond_mask to mask vmulh[u].vv. For vmulsu.vv, it can not be produced in midend currently. We will send another patch to take this issue. gcc/ChangeLog: * config/riscv/autovec-opt.md (*cond_<mulh_table><mode>3_highpart): New combine pattern. * config/riscv/autovec.md (smul<mode>3_highpart): Mrege smul and umul. (<mulh_table><mode>3_highpart): Merged pattern. (umul<mode>3_highpart): Mrege smul and umul. * config/riscv/vector-iterators.md (umul): New iterators. (UNSPEC_VMULHU): New iterators. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/cond/cond_mulh-1.c: New test. * gcc.target/riscv/rvv/autovec/cond/cond_mulh-2.c: New test. * gcc.target/riscv/rvv/autovec/cond/cond_mulh_run-1.c: New test. * gcc.target/riscv/rvv/autovec/cond/cond_mulh_run-2.c: New test.
2023-09-13RISC-V: Support cond vnsrl/vnsra autovec patternsLehua Ding7-0/+223
This patch add combine patterns to combine vnsra.w[vxi] + vcond_mask to a mask vnsra.w[vxi]. gcc/ChangeLog: * config/riscv/autovec-opt.md (*cond_v<any_shiftrt:optab><any_extend:optab>trunc<mode>): New combine pattern. (*cond_<any_shiftrt:optab>trunc<mode>): Ditto. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/cond/cond_narrow_shift-1.c: New test. * gcc.target/riscv/rvv/autovec/cond/cond_narrow_shift-2.c: New test. * gcc.target/riscv/rvv/autovec/cond/cond_narrow_shift-3.c: New test. * gcc.target/riscv/rvv/autovec/cond/cond_narrow_shift_run-1.c: New test. * gcc.target/riscv/rvv/autovec/cond/cond_narrow_shift_run-2.c: New test. * gcc.target/riscv/rvv/autovec/cond/cond_narrow_shift_run-3.c: New test.
2023-09-13RISC-V: Support cond vfsgnj.vv autovec patternsLehua Ding7-20/+350
This patch add combine patterns to combine vfsgnj.vv + vcond_mask to mask vfsgnj.vv. For vfsgnjx.vv, it can not be produced in midend currently. We will send another patch to take this issue. gcc/ChangeLog: * config/riscv/autovec-opt.md (*copysign<mode>_neg): Move. (*cond_copysign<mode>): New combine pattern. * config/riscv/riscv-v.cc (needs_fp_rounding): Extend. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/cond/cond_copysign-run.c: New test. * gcc.target/riscv/rvv/autovec/cond/cond_copysign-rv32gcv.c: New test. * gcc.target/riscv/rvv/autovec/cond/cond_copysign-rv64gcv.c: New test. * gcc.target/riscv/rvv/autovec/cond/cond_copysign-template.h: New test. * gcc.target/riscv/rvv/autovec/cond/cond_copysign-zvfh-run.c: New test.
2023-09-13tree-optimization/111397 - missed copy propagation involving abnormal destRichard Biener4-10/+32
The following extends the previous enhancement to copy propagation involving abnormals. We can easily replace abnormal uses by not abnormal uses and only need to preserve the abnormals in PHI arguments flowing in from abnormal edges. This changes the may_propagate_copy argument indicating we are not propagating into a PHI node to indicate whether we know we are not propagating into a PHI argument from an abnormal PHI instead. PR tree-optimization/111397 * tree-ssa-propagate.cc (may_propagate_copy): Change optional argument to specify whether the PHI destination doesn't flow in from an abnormal PHI. (propagate_value): Adjust. * tree-ssa-forwprop.cc (pass_forwprop::execute): Indicate abnormal PHI dest. * tree-ssa-sccvn.cc (eliminate_dom_walker::before_dom_children): Likewise. (process_bb): Likewise. * gcc.dg/uninit-pr111397.c: New testcase.
2023-09-13RISC-V: Bugfix PR111362 for incorrect frm emitPan Li2-1/+13
When the mode switching from NONE to CALL, we will restore the frm but lack some check if we have static frm insn in cfun. This patch would like to fix this by adding static frm insn check. PR target/111362 gcc/ChangeLog: * config/riscv/riscv.cc (riscv_emit_frm_mode_set): Bugfix. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/base/no-honor-frm-1.c: New test. Signed-off-by: Pan Li <pan2.li@intel.com>
2023-09-13RISC-V: Remove redundant ABI testJuzhe-Zhong1-16/+0
We only support and report warning for RVV types. We don't report warning for GNU vectors. So this testcase checking is incorrect and the FAIL is bogus. Remove it and commit it. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/base/vector-abi-9.c: Removed.
2023-09-13Checking undefined_p before using the vrJiufu Guo2-0/+14
For pattern "(X + C) / N": "div (plus@3 @0 INTEGER_CST@1) INTEGER_CST@2)", Even if "X" has value-range and "X + C" does not overflow, "@3" may still be undefined. Like below example: _3 = _2 + -5; if (0 != 0) goto <bb 3>; [34.00%] else goto <bb 4>; [66.00%] ;; succ: 3 ;; 4 ;; basic block 3, loop depth 0 ;; pred: 2 _5 = _3 / 5; ;; succ: 4 The whole pattern "(_2 + -5 ) / 5" is in "bb 3", but "bb 3" would be unreachable (because "if (0 != 0)" is always false). And "get_range_query (cfun)->range_of_expr (vr3, @3)" is checked in "bb 3", "range_of_expr" gets an "undefined vr3". Where "@3" is "_5". So, before using "vr3", it would be safe to check "!vr3.undefined_p ()". PR tree-optimization/111303 gcc/ChangeLog: * match.pd ((X - N * M) / N): Add undefined_p checking. ((X + N * M) / N): Likewise. ((X + C) div_rshift N): Likewise. gcc/testsuite/ChangeLog: * gcc.dg/pr111303.c: New test.
2023-09-13Daily bump.GCC Administrator11-1/+694
2023-09-12RISC-V: Enable vec_int testsuite for RVV VLA vectorizationJuzhe-Zhong1-14/+45
This patch is the final version of enabling vect_int test for RVV. There are still 80+ FAILs and they can't be fixed by adjusting testcases or target-supports.exp Here is the analysis of **ALL** FAILs: 1. REAL highest priority FAILs: ICE: FAIL: gcc.dg/vect/vect-live-6.c (internal compiler error: in force_align_down_and_div, at poly-int.h:1903) FAIL: gcc.dg/vect/vect-live-6.c (test for excess errors) FAIL: gcc.dg/vect/vect-live-6.c -flto -ffat-lto-objects (internal compiler error: in force_align_down_and_div, at poly-int.h:1903) FAIL: gcc.dg/vect/vect-live-6.c -flto -ffat-lto-objects (test for excess errors) Execution fails: FAIL: gcc.dg/vect/slp-reduc-7.c -flto -ffat-lto-objects execution test FAIL: gcc.dg/vect/slp-reduc-7.c execution test FAIL: gcc.dg/vect/vect-alias-check-10.c -flto -ffat-lto-objects execution test FAIL: gcc.dg/vect/vect-alias-check-10.c execution test FAIL: gcc.dg/vect/vect-alias-check-11.c -flto -ffat-lto-objects execution test FAIL: gcc.dg/vect/vect-alias-check-11.c execution test FAIL: gcc.dg/vect/vect-alias-check-12.c -flto -ffat-lto-objects execution test FAIL: gcc.dg/vect/vect-alias-check-12.c execution test FAIL: gcc.dg/vect/vect-alias-check-14.c -flto -ffat-lto-objects execution test FAIL: gcc.dg/vect/vect-alias-check-14.c execution test FAIL: gcc.dg/vect/vect-double-reduc-5.c -flto -ffat-lto-objects execution test FAIL: gcc.dg/vect/vect-double-reduc-5.c execution test These FAILs are REAL problem that we need to address first. 2. Missed optimizations due to lacking VLS modes patterns: FAIL: gcc.dg/vect/pr57705.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorized 1 loop" 2 FAIL: gcc.dg/vect/pr57705.c scan-tree-dump-times vect "vectorized 1 loop" 2 FAIL: gcc.dg/vect/pr65518.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorized 0 loops in function" 2 FAIL: gcc.dg/vect/pr65518.c scan-tree-dump-times vect "vectorized 0 loops in function" 2 FAIL: gcc.dg/vect/slp-1.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorizing stmts using SLP" 4 FAIL: gcc.dg/vect/slp-1.c scan-tree-dump-times vect "vectorizing stmts using SLP" 4 FAIL: gcc.dg/vect/slp-12a.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorizing stmts using SLP" 1 FAIL: gcc.dg/vect/slp-12a.c scan-tree-dump-times vect "vectorizing stmts using SLP" 1 FAIL: gcc.dg/vect/slp-16.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorizing stmts using SLP" 2 FAIL: gcc.dg/vect/slp-16.c scan-tree-dump-times vect "vectorizing stmts using SLP" 2 FAIL: gcc.dg/vect/slp-34-big-array.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorizing stmts using SLP" 2 FAIL: gcc.dg/vect/slp-34-big-array.c scan-tree-dump-times vect "vectorizing stmts using SLP" 2 FAIL: gcc.dg/vect/slp-34.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorizing stmts using SLP" 2 FAIL: gcc.dg/vect/slp-34.c scan-tree-dump-times vect "vectorizing stmts using SLP" 2 FAIL: gcc.dg/vect/slp-35.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorizing stmts using SLP" 1 FAIL: gcc.dg/vect/slp-35.c scan-tree-dump-times vect "vectorizing stmts using SLP" 1 FAIL: gcc.dg/vect/slp-43.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorized 1 loops" 13 FAIL: gcc.dg/vect/slp-43.c scan-tree-dump-times vect "vectorized 1 loops" 13 FAIL: gcc.dg/vect/slp-45.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorized 1 loops" 13 FAIL: gcc.dg/vect/slp-45.c scan-tree-dump-times vect "vectorized 1 loops" 13 FAIL: gcc.dg/vect/slp-47.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorizing stmts using SLP" 2 FAIL: gcc.dg/vect/slp-47.c scan-tree-dump-times vect "vectorizing stmts using SLP" 2 FAIL: gcc.dg/vect/slp-48.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorizing stmts using SLP" 2 FAIL: gcc.dg/vect/slp-48.c scan-tree-dump-times vect "vectorizing stmts using SLP" 2 These testcases need VLS modes vec_init patterns. FAIL: gcc.dg/vect/vect-bic-bitmask-12.c -flto -ffat-lto-objects scan-tree-dump dce7 "<=\\s*.+{ 255,.+}" FAIL: gcc.dg/vect/vect-bic-bitmask-12.c scan-tree-dump dce7 "<=\\s*.+{ 255,.+}" FAIL: gcc.dg/vect/vect-bic-bitmask-23.c -flto -ffat-lto-objects scan-tree-dump dce7 "<=\\s*.+{ 255, 15, 1, 65535 }" FAIL: gcc.dg/vect/vect-bic-bitmask-23.c scan-tree-dump dce7 "<=\\s*.+{ 255, 15, 1, 65535 }" These testcases need VLS modes VCOND_MASK and vec_cmp patterns. 3. Maybe bogus dump check FAILs: FAIL: gcc.dg/vect/vect-multitypes-11.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorized 1 loops" 1 FAIL: gcc.dg/vect/vect-multitypes-11.c scan-tree-dump-times vect "vectorized 1 loops" 1 FAIL: gcc.dg/vect/vect-outer-4c-big-array.c -flto -ffat-lto-objects scan-tree-dump-times vect "zero step in outer loop." 1 FAIL: gcc.dg/vect/vect-outer-4c-big-array.c scan-tree-dump-times vect "zero step in outer loop." 1 FAIL: gcc.dg/vect/vect-reduc-dot-s16a.c -flto -ffat-lto-objects scan-tree-dump-times vect "vect_recog_dot_prod_pattern: detected" 1 FAIL: gcc.dg/vect/vect-reduc-dot-s16a.c scan-tree-dump-times vect "vect_recog_dot_prod_pattern: detected" 1 FAIL: gcc.dg/vect/vect-reduc-dot-s8a.c -flto -ffat-lto-objects scan-tree-dump-times vect "vect_recog_dot_prod_pattern: detected" 1 FAIL: gcc.dg/vect/vect-reduc-dot-s8a.c -flto -ffat-lto-objects scan-tree-dump-times vect "vect_recog_widen_mult_pattern: detected" 1 FAIL: gcc.dg/vect/vect-reduc-dot-s8a.c scan-tree-dump-times vect "vect_recog_dot_prod_pattern: detected" 1 FAIL: gcc.dg/vect/vect-reduc-dot-s8a.c scan-tree-dump-times vect "vect_recog_widen_mult_pattern: detected" 1 FAIL: gcc.dg/vect/vect-reduc-dot-s8b.c -flto -ffat-lto-objects scan-tree-dump-times vect "vect_recog_widen_mult_pattern: detected" 1 FAIL: gcc.dg/vect/vect-reduc-dot-s8b.c scan-tree-dump-times vect "vect_recog_widen_mult_pattern: detected" 1 FAIL: gcc.dg/vect/vect-reduc-dot-u16b.c -flto -ffat-lto-objects scan-tree-dump-times vect "vect_recog_dot_prod_pattern: detected" 1 FAIL: gcc.dg/vect/vect-reduc-dot-u16b.c scan-tree-dump-times vect "vect_recog_dot_prod_pattern: detected" 1 FAIL: gcc.dg/vect/vect-reduc-dot-u8a.c -flto -ffat-lto-objects scan-tree-dump-times vect "vect_recog_dot_prod_pattern: detected" 1 FAIL: gcc.dg/vect/vect-reduc-dot-u8a.c scan-tree-dump-times vect "vect_recog_dot_prod_pattern: detected" 1 FAIL: gcc.dg/vect/vect-reduc-dot-u8b.c -flto -ffat-lto-objects scan-tree-dump-times vect "vect_recog_dot_prod_pattern: detected" 1 FAIL: gcc.dg/vect/vect-reduc-dot-u8b.c scan-tree-dump-times vect "vect_recog_dot_prod_pattern: detected" 1 FAIL: gcc.dg/vect/vect-reduc-pattern-1a.c -flto -ffat-lto-objects scan-tree-dump-times vect "vect_recog_widen_sum_pattern: detected" 1 FAIL: gcc.dg/vect/vect-reduc-pattern-1a.c scan-tree-dump-times vect "vect_recog_widen_sum_pattern: detected" 1 FAIL: gcc.dg/vect/vect-reduc-pattern-1b-big-array.c -flto -ffat-lto-objects scan-tree-dump-times vect "vect_recog_widen_sum_pattern: detected" 1 FAIL: gcc.dg/vect/vect-reduc-pattern-1b-big-array.c scan-tree-dump-times vect "vect_recog_widen_sum_pattern: detected" 1 FAIL: gcc.dg/vect/vect-reduc-pattern-1c-big-array.c -flto -ffat-lto-objects scan-tree-dump-times vect "vect_recog_widen_sum_pattern: detected" 1 FAIL: gcc.dg/vect/vect-reduc-pattern-1c-big-array.c scan-tree-dump-times vect "vect_recog_widen_sum_pattern: detected" 1 FAIL: gcc.dg/vect/vect-reduc-pattern-2a.c -flto -ffat-lto-objects scan-tree-dump-times vect "vect_recog_widen_sum_pattern: detected" 1 FAIL: gcc.dg/vect/vect-reduc-pattern-2a.c scan-tree-dump-times vect "vect_recog_widen_sum_pattern: detected" 1 FAIL: gcc.dg/vect/vect-reduc-pattern-2b-big-array.c -flto -ffat-lto-objects scan-tree-dump-times vect "vect_recog_widen_sum_pattern: detected" 1 FAIL: gcc.dg/vect/vect-reduc-pattern-2b-big-array.c scan-tree-dump-times vect "vect_recog_widen_sum_pattern: detected" 1 FAIL: gcc.dg/vect/wrapv-vect-reduc-dot-s8b.c scan-tree-dump-times vect "vect_recog_dot_prod_pattern: detected" 1 FAIL: gcc.dg/vect/wrapv-vect-reduc-dot-s8b.c scan-tree-dump-times vect "vect_recog_widen_mult_pattern: detected" 1 These testcases because we don't support widen_sum/vec_unpack....etc patterns. Currently, we don't support them since we don't see the benefits. May support those patterns if they are beneficial ? Or Fix testcases ? Conclusion: IMHO, I think we can merge this patch after we addressed all REAL highest priority issues (1). The rest FAILs are not big issues then we can reduce them by supporting more features (For example VLS modes). Feel free to give any comments. gcc/testsuite/ChangeLog: * lib/target-supports.exp: Enable vect_int for RVV.
2023-09-12RISC-V: Support VECTOR BOOL vcond_mask optab[PR111337]Juzhe-Zhong1-0/+34
As this PR: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111337 We support VECTOR BOOL vcond_mask to fix this following ICE: 0x1a9e309 gimple_expand_vec_cond_expr ../../../../gcc/gcc/gimple-isel.cc:283 0x1a9ea56 execute ../../../../gcc/gcc/gimple-isel.cc:390 gcc/ChangeLog: PR target/111337 * config/riscv/autovec.md (vcond_mask_<mode><mode>): New pattern.
2023-09-12libgo: fix DejaGNU testsuite compiler when using build sysrootIan Lance Taylor7-4/+19
Patch from Thomas Schwinge. PR testsuite/109951 * configure.ac: 'AC_SUBST(SYSROOT_CFLAGS_FOR_TARGET)'. * Makefile.in: Regenerate. * configure: Likewise. * testsuite/Makefile.in: Likewise. * testsuite/lib/libgo.exp (libgo_init): If '--with-build-sysroot=[...]' was specified, use it for build-tree testing. * testsuite/libgo-test-support.exp.in (GOC_UNDER_TEST): Don't set. (SYSROOT_CFLAGS_FOR_TARGET): Set. Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/527755
2023-09-12c++: __integer_pack with class argument [PR111357]Jason Merrill2-0/+40
The argument might not already be an integer. PR c++/111357 gcc/cp/ChangeLog: * pt.cc (expand_integer_pack): Convert argument to int. gcc/testsuite/ChangeLog: * g++.dg/ext/integer-pack7.C: New test.
2023-09-12c++: ICE with -fno-exceptions and array init [PR107198]Jason Merrill2-1/+19
The removed line no longer has an effect on anew5.C error recovery, and removing it improves error recovery for this testcase. PR c++/107198 gcc/cp/ChangeLog: * typeck2.cc (process_init_constructor_array): Use VEC_INIT_EXPR regardless of seen_error. gcc/testsuite/ChangeLog: * g++.dg/eh/no-exceptions1.C: New test.
2023-09-12math-opts: Add dbgcounter for FMA formationMartin Jambor2-0/+5
This patch is a simple addition of a debug counter to FMA formation in tree-ssa-math-opts.cc. Given that issues with FMAs do occasionally pop up, it seems genuinely useful. I simply added an if right after the initial checks in convert_mult_to_fma even though when FMA formation deferring is active (i.e. when targeting Zen CPUs) this would interact with it (and at this moment lead to producing all deferred candidates), so when using the dbg counter to find a harmful set of FMAs, it is probably best to also set param_avoid_fma_max_bits to zero. I could not find a better place which would not also make the code unnecessarily more complicated. gcc/ChangeLog: 2023-09-06 Martin Jambor <mjambor@suse.cz> * dbgcnt.def (form_fma): New. * tree-ssa-math-opts.cc: Include dbgcnt.h. (convert_mult_to_fma): Bail out if the debug counter say so.
2023-09-12MAINTAINERS: Add myself to write after approvalEdwin Lu1-0/+1
ChangeLog: * MAINTAINERS: Add myself
2023-09-12RISC-V: Finish Typing Un-Typed Instructions and Turn on AssertEdwin Lu2-3/+2
Updates autovec instruction that was added after last patch and turns on the assert statement to ensure all new instructions have a type. * config/riscv/autovec-opt.md: Update type * config/riscv/riscv.cc (riscv_sched_variable_issue): Enable assert Reviewed-by: Jeff Law <jlaw@ventanamicro.com> Signed-off-by: Edwin Lu <ewlu@rivosinc.com>
2023-09-12libstdc++: Fix std::not_fn perfect forwarding [PR111327]Patrick Palka2-2/+37
The previous patch fixed perfect forwarding in std::bind_front. This patch fixes the same issue in std::not_fn. PR libstdc++/111327 libstdc++-v3/ChangeLog: * include/std/functional (_GLIBCXX_NOT_FN_CALL_OP): Also define a deleted fallback operator() overload. Constrain both the enabled and deleted overloads accordingly. * testsuite/20_util/function_objects/not_fn/111327.cc: New test.
2023-09-12libstdc++: Fix std::bind_front perfect forwarding [PR111327]Patrick Palka2-0/+57
In order to properly implement a perfect forwarding call wrapper (without C++23 deducing 'this') we need a total of 8 operator() overloads, 4 enabled ones and 4 deleted ones, i.e. two for each const/ref qual pair, as described in section 5.5 of P0847R6. Otherwise the wrapper may not do the right thing if the underlying function object has a deleted const/ref-qualified operator() overload. This patch fixes this issue in std::bind_front. PR libstdc++/111327 libstdc++-v3/ChangeLog: * include/std/functional (_Bind_front::operator()): Add deleted fallback overloads for each const/ref qualifier pair. Give the enabled overloads dummy constraints to make each one more specialized than the corresponding deleted overload. * testsuite/20_util/function_objects/bind_front/111327.cc: New test.
2023-09-12libstdc++: Remove std::bind_front specialization for no bound argsPatrick Palka1-62/+1
The specialization used by std::bind_front when there are no bound args (added by r13-4214-gcbd05ca5ab1231) seems to be mostly obsoleted by r13-5033-ge2eab3c4edb6aa which added [[no_unique_address]] to the main template's data members. What's left to consider is the compile time advantage of the specialization, which doesn't seem huge since it just avoids using tuple<> (which is an explicit specialization anyway) and expanding some pack expansions with an empty argument pack. So this patch removes this specialization; this means we have one less spot to fix the PR libstdc++/111327 perfect forwarding bug. libstdc++-v3/ChangeLog: * include/std/functional (_Bind_front0): Remove. (_Bind_front_t): Adjust.
2023-09-12aarch64: Make stack smash canary protect saved registersRichard Sandiford3-6/+168
AArch64 normally puts the saved registers near the bottom of the frame, immediately above any dynamic allocations. But this means that a stack-smash attack on those dynamic allocations could overwrite the saved registers without needing to reach as far as the stack smash canary. The same thing could also happen for variable-sized arguments that are passed by value, since those are allocated before a call and popped on return. This patch avoids that by putting the locals (and thus the canary) below the saved registers when stack smash protection is active. The patch fixes CVE-2023-4039. gcc/ * config/aarch64/aarch64.cc (aarch64_save_regs_above_locals_p): New function. (aarch64_layout_frame): Use it to decide whether locals should go above or below the saved registers. (aarch64_expand_prologue): Update stack layout comment. Emit a stack tie after the final adjustment. gcc/testsuite/ * gcc.target/aarch64/stack-protector-8.c: New test. * gcc.target/aarch64/stack-protector-9.c: Likewise.
2023-09-12aarch64: Remove below_hard_fp_saved_regs_sizeRichard Sandiford2-31/+21
After previous patches, it's no longer necessary to store saved_regs_size and below_hard_fp_saved_regs_size in the frame info. All measurements instead use the top or bottom of the frame as reference points. gcc/ * config/aarch64/aarch64.h (aarch64_frame::saved_regs_size) (aarch64_frame::below_hard_fp_saved_regs_size): Delete. * config/aarch64/aarch64.cc (aarch64_layout_frame): Update accordingly.
2023-09-12aarch64: Explicitly record probe registers in frame infoRichard Sandiford3-18/+64
The stack frame is currently divided into three areas: A: the area above the hard frame pointer B: the SVE saves below the hard frame pointer C: the outgoing arguments If the stack frame is allocated in one chunk, the allocation needs a probe if the frame size is >= guard_size - 1KiB. In addition, if the function is not a leaf function, it must probe an address no more than 1KiB above the outgoing SP. We ensured the second condition by (1) using single-chunk allocations for non-leaf functions only if the link register save slot is within 512 bytes of the bottom of the frame; and (2) using the link register save as a probe (meaning, for instance, that it can't be individually shrink wrapped) If instead the stack is allocated in multiple chunks, then: * an allocation involving only the outgoing arguments (C above) requires a probe if the allocation size is > 1KiB * any other allocation requires a probe if the allocation size is >= guard_size - 1KiB * second and subsequent allocations require the previous allocation to probe at the bottom of the allocated area, regardless of the size of that previous allocation The final point means that, unlike for single allocations, it can be necessary to have both a non-SVE register probe and an SVE register probe. For example: * allocate A, probe using a non-SVE register save * allocate B, probe using an SVE register save * allocate C The non-SVE register used in this case was again the link register. It was previously used even if the link register save slot was some bytes above the bottom of the non-SVE register saves, but an earlier patch avoided that by putting the link register save slot first. As a belt-and-braces fix, this patch explicitly records which probe registers we're using and allows the non-SVE probe to be whichever register comes first (as for SVE). The patch also avoids unnecessary probes in sve/pcs/stack_clash_3.c. gcc/ * config/aarch64/aarch64.h (aarch64_frame::sve_save_and_probe) (aarch64_frame::hard_fp_save_and_probe): New fields. * config/aarch64/aarch64.cc (aarch64_layout_frame): Initialize them. Rather than asserting that a leaf function saves LR, instead assert that a leaf function saves something. (aarch64_get_separate_components): Prevent the chosen probe registers from being individually shrink-wrapped. (aarch64_allocate_and_probe_stack_space): Remove workaround for probe registers that aren't at the bottom of the previous allocation. gcc/testsuite/ * gcc.target/aarch64/sve/pcs/stack_clash_3.c: Avoid redundant probes.
2023-09-12aarch64: Simplify probe of final frame allocationRichard Sandiford4-13/+9
Previous patches ensured that the final frame allocation only needs a probe when the size is strictly greater than 1KiB. It's therefore safe to use the normal 1024 probe offset in all cases. The main motivation for doing this is to simplify the code and remove the number of special cases. gcc/ * config/aarch64/aarch64.cc (aarch64_allocate_and_probe_stack_space): Always probe the residual allocation at offset 1024, asserting that that is in range. gcc/testsuite/ * gcc.target/aarch64/stack-check-prologue-17.c: Expect the probe to be at offset 1024 rather than offset 0. * gcc.target/aarch64/stack-check-prologue-18.c: Likewise. * gcc.target/aarch64/stack-check-prologue-19.c: Likewise.
2023-09-12aarch64: Put LR save probe in first 16 bytesRichard Sandiford4-42/+233
-fstack-clash-protection uses the save of LR as a probe for the next allocation. The next allocation could be: * another part of the static frame, e.g. when allocating SVE save slots or outgoing arguments * an alloca in the same function * an allocation made by a callee function However, when -fomit-frame-pointer is used, the LR save slot is placed above the other GPR save slots. It could therefore be up to 80 bytes above the base of the GPR save area (which is also the hard fp address). aarch64_allocate_and_probe_stack_space took this into account when deciding how much subsequent space could be allocated without needing a probe. However, it interacted badly with: /* If doing a small final adjustment, we always probe at offset 0. This is done to avoid issues when LR is not at position 0 or when the final adjustment is smaller than the probing offset. */ else if (final_adjustment_p && rounded_size == 0) residual_probe_offset = 0; which forces any allocation that is smaller than the guard page size to be probed at offset 0 rather than the usual offset 1024. It was therefore possible to construct cases in which we had: * a probe using LR at SP + 80 bytes (or some other value >= 16) * an allocation of the guard page size - 16 bytes * a probe at SP + 0 which allocates guard page size + 64 consecutive unprobed bytes. This patch requires the LR probe to be in the first 16 bytes of the save area when stack clash protection is active. Doing it unconditionally would cause code-quality regressions. Putting LR before other registers prevents push/pop allocation when shadow call stacks are enabled, since LR is restored separately from the other callee-saved registers. The new comment doesn't say that the probe register is required to be LR, since a later patch removes that restriction. gcc/ * config/aarch64/aarch64.cc (aarch64_layout_frame): Ensure that the LR save slot is in the first 16 bytes of the register save area. Only form STP/LDP push/pop candidates if both registers are valid. (aarch64_allocate_and_probe_stack_space): Remove workaround for when LR was not in the first 16 bytes. gcc/testsuite/ * gcc.target/aarch64/stack-check-prologue-18.c: New test. * gcc.target/aarch64/stack-check-prologue-19.c: Likewise. * gcc.target/aarch64/stack-check-prologue-20.c: Likewise.
2023-09-12aarch64: Tweak stack clash boundary conditionRichard Sandiford2-1/+58
The AArch64 ABI says that, when stack clash protection is used, there can be a maximum of 1KiB of unprobed space at sp on entry to a function. Therefore, we need to probe when allocating >= guard_size - 1KiB of data (>= rather than >). This is what GCC does. If an allocation is exactly guard_size bytes, it is enough to allocate those bytes and probe once at offset 1024. It isn't possible to use a single probe at any other offset: higher would conmplicate later code, by leaving more unprobed space than usual, while lower would risk leaving an entire page unprobed. For simplicity, the code probes all allocations at offset 1024. Some register saves also act as probes. If we need to allocate more space below the last such register save probe, we need to probe the allocation if it is > 1KiB. Again, this allocation is then sometimes (but not always) probed at offset 1024. This sort of allocation is currently only used for outgoing arguments, which are rarely this big. However, the code also probed if this final outgoing-arguments allocation was == 1KiB, rather than just > 1KiB. This isn't necessary, since the register save then probes at offset 1024 as required. Continuing to probe allocations of exactly 1KiB would complicate later patches. gcc/ * config/aarch64/aarch64.cc (aarch64_allocate_and_probe_stack_space): Don't probe final allocations that are exactly 1KiB in size (after unprobed space above the final allocation has been deducted). gcc/testsuite/ * gcc.target/aarch64/stack-check-prologue-17.c: New test.
2023-09-12aarch64: Minor initial adjustment tweakRichard Sandiford1-3/+2
This patch just changes a calculation of initial_adjust to one that makes it slightly more obvious that the total adjustment is frame.frame_size. gcc/ * config/aarch64/aarch64.cc (aarch64_layout_frame): Tweak calculation of initial_adjust for frames in which all saves are SVE saves.
2023-09-12aarch64: Simplify top of frame allocationRichard Sandiford1-15/+8
After previous patches, it no longer really makes sense to allocate the top of the frame in terms of varargs_and_saved_regs_size and saved_regs_and_above. gcc/ * config/aarch64/aarch64.cc (aarch64_layout_frame): Simplify the allocation of the top of the frame.
2023-09-12aarch64: Measure reg_offset from the bottom of the frameRichard Sandiford2-29/+27
reg_offset was measured from the bottom of the saved register area. This made perfect sense with the original layout, since the bottom of the saved register area was also the hard frame pointer address. It became slightly less obvious with SVE, since we save SVE registers below the hard frame pointer, but it still made sense. However, if we want to allow different frame layouts, it's more convenient and obvious to measure reg_offset from the bottom of the frame. After previous patches, it's also a slight simplification in its own right. gcc/ * config/aarch64/aarch64.h (aarch64_frame): Add comment above reg_offset. * config/aarch64/aarch64.cc (aarch64_layout_frame): Walk offsets from the bottom of the frame, rather than the bottom of the saved register area. Measure reg_offset from the bottom of the frame rather than the bottom of the saved register area. (aarch64_save_callee_saves): Update accordingly. (aarch64_restore_callee_saves): Likewise. (aarch64_get_separate_components): Likewise. (aarch64_process_components): Likewise.
2023-09-12aarch64: Tweak frame_size commentRichard Sandiford1-2/+2
This patch fixes another case in which a value was described with an “upside-down” view. gcc/ * config/aarch64/aarch64.h (aarch64_frame::frame_size): Tweak comment.
2023-09-12aarch64: Rename hard_fp_offset to bytes_above_hard_fpRichard Sandiford2-16/+16
Similarly to the previous locals_offset patch, hard_fp_offset was described as: /* Offset from the base of the frame (incomming SP) to the hard_frame_pointer. This value is always a multiple of STACK_BOUNDARY. */ poly_int64 hard_fp_offset; which again took an “upside-down” view: higher offsets meant lower addresses. This patch renames the field to bytes_above_hard_fp instead. gcc/ * config/aarch64/aarch64.h (aarch64_frame::hard_fp_offset): Rename to... (aarch64_frame::bytes_above_hard_fp): ...this. * config/aarch64/aarch64.cc (aarch64_layout_frame) (aarch64_expand_prologue): Update accordingly. (aarch64_initial_elimination_offset): Likewise.
2023-09-12aarch64: Rename locals_offset to bytes_above_localsRichard Sandiford2-6/+6
locals_offset was described as: /* Offset from the base of the frame (incomming SP) to the top of the locals area. This value is always a multiple of STACK_BOUNDARY. */ This is implicitly an “upside down” view of the frame: the incoming SP is at offset 0, and anything N bytes below the incoming SP is at offset N (rather than -N). However, reg_offset instead uses a “right way up” view; that is, it views offsets in address terms. Something above X is at a positive offset from X and something below X is at a negative offset from X. Also, even on FRAME_GROWS_DOWNWARD targets like AArch64, target-independent code views offsets in address terms too: locals are allocated at negative offsets to virtual_stack_vars. It seems confusing to have *_offset fields of the same structure using different polarities like this. This patch tries to avoid that by renaming locals_offset to bytes_above_locals. gcc/ * config/aarch64/aarch64.h (aarch64_frame::locals_offset): Rename to... (aarch64_frame::bytes_above_locals): ...this. * config/aarch64/aarch64.cc (aarch64_layout_frame) (aarch64_initial_elimination_offset): Update accordingly.
2023-09-12aarch64: Only calculate chain_offset if there is a chainRichard Sandiford1-5/+5
After previous patches, it is no longer necessary to calculate a chain_offset in cases where there is no chain record. gcc/ * config/aarch64/aarch64.cc (aarch64_expand_prologue): Move the calculation of chain_offset into the emit_frame_chain block.
2023-09-12aarch64: Tweak aarch64_save/restore_callee_savesRichard Sandiford2-32/+28
aarch64_save_callee_saves and aarch64_restore_callee_saves took a parameter called start_offset that gives the offset of the bottom of the saved register area from the current stack pointer. However, it's more convenient for later patches if we use the bottom of the entire frame as the reference point, rather than the bottom of the saved registers. Doing that removes the need for the callee_offset field. Other than that, this is not a win on its own. It only really makes sense in combination with the follow-on patches. gcc/ * config/aarch64/aarch64.h (aarch64_frame::callee_offset): Delete. * config/aarch64/aarch64.cc (aarch64_layout_frame): Remove callee_offset handling. (aarch64_save_callee_saves): Replace the start_offset parameter with a bytes_below_sp parameter. (aarch64_restore_callee_saves): Likewise. (aarch64_expand_prologue): Update accordingly. (aarch64_expand_epilogue): Likewise.
2023-09-12aarch64: Add bytes_below_hard_fp to frame infoRichard Sandiford2-3/+8
Following on from the previous bytes_below_saved_regs patch, this one records the number of bytes that are below the hard frame pointer. This eventually replaces below_hard_fp_saved_regs_size. If a frame pointer is not needed, the epilogue adds final_adjust to the stack pointer before restoring registers: aarch64_add_sp (tmp1_rtx, tmp0_rtx, final_adjust, true); Therefore, if the epilogue needs to restore the stack pointer from the hard frame pointer, the directly corresponding offset is: -bytes_below_hard_fp + final_adjust i.e. go from the hard frame pointer to the bottom of the frame, then add the same amount as if we were using the stack pointer from the outset. gcc/ * config/aarch64/aarch64.h (aarch64_frame::bytes_below_hard_fp): New field. * config/aarch64/aarch64.cc (aarch64_layout_frame): Initialize it. (aarch64_expand_epilogue): Use it instead of below_hard_fp_saved_regs_size.
2023-09-12aarch64: Add bytes_below_saved_regs to frame infoRichard Sandiford2-35/+41
The frame layout code currently hard-codes the assumption that the number of bytes below the saved registers is equal to the size of the outgoing arguments. This patch abstracts that value into a new field of aarch64_frame. gcc/ * config/aarch64/aarch64.h (aarch64_frame::bytes_below_saved_regs): New field. * config/aarch64/aarch64.cc (aarch64_layout_frame): Initialize it, and use it instead of crtl->outgoing_args_size. (aarch64_get_separate_components): Use bytes_below_saved_regs instead of outgoing_args_size. (aarch64_process_components): Likewise.
2023-09-12aarch64: Explicitly handle frames with no saved registersRichard Sandiford1-3/+5
If a frame has no saved registers, it can be allocated in one go. There is no need to treat the areas below and above the saved registers as separate. And if we allocate the frame in one go, it should be allocated as the initial_adjust rather than the final_adjust. This allows the frame size to grow to guard_size - guard_used_by_caller before a stack probe is needed. (A frame with no register saves is necessarily a leaf frame.) This is a no-op as thing stand, since a leaf function will have no outgoing arguments, and so all the frame will be above where the saved registers normally go. gcc/ * config/aarch64/aarch64.cc (aarch64_layout_frame): Explicitly allocate the frame in one go if there are no saved registers.
2023-09-12aarch64: Avoid a use of callee_offsetRichard Sandiford1-3/+1
When we emit the frame chain, i.e. when we reach Here in this statement of aarch64_expand_prologue: if (emit_frame_chain) { // Here ... } the stack is in one of two states: - We've allocated up to the frame chain, but no more. - We've allocated the whole frame, and the frame chain is within easy reach of the new SP. The offset of the frame chain from the current SP is available in aarch64_frame as callee_offset. It is also available as the chain_offset local variable, where the latter is calculated from other data. (However, chain_offset is not always equal to callee_offset when !emit_frame_chain, so chain_offset isn't redundant.) In c600df9a4060da3c6121ff4d0b93f179eafd69d1 I switched to using chain_offset for the initialisation of the hard frame pointer: aarch64_add_offset (Pmode, hard_frame_pointer_rtx, - stack_pointer_rtx, callee_offset, + stack_pointer_rtx, chain_offset, tmp1_rtx, tmp0_rtx, frame_pointer_needed); But the later REG_CFA_ADJUST_CFA handling still used callee_offset. I think the difference is harmless, but it's more logical for the CFA note to be in sync, and it's more convenient for later patches if it uses chain_offset. gcc/ * config/aarch64/aarch64.cc (aarch64_expand_prologue): Use chain_offset rather than callee_offset.
2023-09-12aarch64: Use local frame vars in shrink-wrapping codeRichard Sandiford1-59/+64
aarch64_layout_frame uses a shorthand for referring to cfun->machine->frame: aarch64_frame &frame = cfun->machine->frame; This patch does the same for some other heavy users of the structure. No functional change intended. gcc/ * config/aarch64/aarch64.cc (aarch64_save_callee_saves): Use a local shorthand for cfun->machine->frame. (aarch64_restore_callee_saves, aarch64_get_separate_components): (aarch64_process_components): Likewise. (aarch64_allocate_and_probe_stack_space): Likewise. (aarch64_expand_prologue, aarch64_expand_epilogue): Likewise. (aarch64_layout_frame): Use existing shorthand for one more case.
2023-09-12MATCH: Simplify (a CMP1 b) ^ (a CMP2 b)Andrew Pinski4-0/+237
This adds the missing optimizations here. Note we don't need to match where CMP1 and CMP2 are complements of each other as that is already handled elsewhere. I added a new executable testcase to make sure we optimize it correctly as I had originally messed up one of the entries for the resulting comparison to make sure they were 100% correct. OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions. PR tree-optimization/107881 gcc/ChangeLog: * match.pd (`(a CMP1 b) ^ (a CMP2 b)`): New pattern. (`(a CMP1 b) == (a CMP2 b)`): New pattern. gcc/testsuite/ChangeLog: * gcc.c-torture/execute/pr107881-1.c: New test. * gcc.dg/tree-ssa/cmpeq-4.c: New test. * gcc.dg/tree-ssa/cmpxor-1.c: New test.
2023-09-12RISC-V: Remove unused structure in cost modelPan Li1-7/+0
The struct range is unused, remove it. gcc/ChangeLog: * config/riscv/riscv-vector-costs.h (struct range): Removed. Signed-off-by: Pan Li <pan2.li@intel.com>
generated by cgit v1.1 at 2025-09-20 22:37:46 +0000