[Bug target/86793] mips port needs updating for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86793 YunQiang Su changed: What|Removed |Added CC||syq at debian dot org --- Comment #2 from YunQiang Su --- Fixed with commit commit 29b74545531f6afbee9fc38c267524326dbfbedf Author: YunQiang Su Date: Thu Jun 1 10:14:24 2023 +0800 MIPS: Add speculation_barrier support speculation_barrier for MIPS needs sync+jr.hb (r2+), so we implement __speculation_barrier in libgcc, like arm32 does.
[Bug target/110273] i686-w64-mingw32 with -march=znver4 generates AVX instructions without stack alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110273 --- Comment #3 from Alexander Monakov --- Seems to work fine with explicit '-mincoming-stack-boundary=2' on the command line, even though it should make no difference for the 32-bit MinGW target.
[Bug target/110264] internal compiler error: riscv_vector::vector_insn_info::get_avl_reg_rtx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110264 --- Comment #3 from JuzheZhong --- I fixed this issue: https://gcc.gnu.org/pipermail/gcc-patches/2023-June/621953.html Hope it will be landed into trunk and backport to GCC-13 soon. Thanks.
[Bug c/110277] New: RISC-V: ICE when build RVV intrinsic float reduction with "-march=rv32gc_zve64d -mabi=ilp32d", both GCC 14 and 13.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110277
Bug ID: 110277
Summary: RISC-V: ICE when build RVV intrinsic float reduction
with "-march=rv32gc_zve64d -mabi=ilp32d", both GCC 14
and 13.
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pan2.li at intel dot com
Target Milestone: ---
Created attachment 55338
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55338&action=edit
Reproduce code
Given we have the below code.
#include "riscv_vector.h"y
vfloat32m1_t test_vfredmax_vs_f32mf2_f32m1(vfloat32mf2_t vector, vfloat32m1_t
scalar, size_t vl) {
return __riscv_vfredmax_vs_f32mf2_f32m1(vector, scalar, vl);
}
There will be the ICE when build similar as "riscv64-unknown-elf-gcc
-march=rv64gc_zve64d -mabi=lp64 -O3 -Wno-psabi -c -S test-float.c -o -".
test-float.c: In function ‘test_vfredmax_vs_f32mf2_f32m1’:
test-float.c:17:10: error: invalid argument to built-in function
17 | return __riscv_vfredmax_vs_f32mf2_f32m1(vector, scalar, vl);
| ^~~~
during RTL pass: expand
test-float.c:17:10: internal compiler error: Segmentation fault
0x16e8945 crash_signal
/home/pli/repos/gcc/555/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/toplev.cc:314
0x7fcc1724251f ???
./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x111c93c store_expr(tree_node*, rtx_def*, int, bool, bool)
/home/pli/repos/gcc/555/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/expr.cc:6345
0x111ae77 expand_assignment(tree_node*, tree_node*, bool)
/home/pli/repos/gcc/555/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/expr.cc:6048
0xf65d2c expand_call_stmt
/home/pli/repos/gcc/555/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/cfgexpand.cc:2829
0xf69ac6 expand_gimple_stmt_1
/home/pli/repos/gcc/555/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/cfgexpand.cc:3880
0xf6a1b3 expand_gimple_stmt
/home/pli/repos/gcc/555/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/cfgexpand.cc:4044
0xf72d20 expand_gimple_basic_block
/home/pli/repos/gcc/555/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/cfgexpand.cc:6096
0xf75279 execute
/home/pli/repos/gcc/555/riscv-gnu-toolchain/gcc/__RISC-V_BUILD__/../gcc/cfgexpand.cc:6831
[Bug tree-optimization/110269] [13/14 Regression] Missed Dead Code Elimination when using __builtin_unreachable since r13-4607-g2dc5d6b1e7e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110269 --- Comment #4 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:827e208fa64771f15fc8e53970a2297e637277b5 commit r14-1880-g827e208fa64771f15fc8e53970a2297e637277b5 Author: Richard Biener Date: Fri Jun 16 08:55:12 2023 +0200 tree-optimization/110269 - restore missed condition folding The following makes sure we optimize x != 0 using range info via tree_expr_nonzero_p via match.pd. PR tree-optimization/110269 * fold-const.cc (fold_binary_loc): Merge x != 0 folding with tree_expr_nonzero_p ... * match.pd (cmp (convert? addr@0) integer_zerop): With this pattern. * gcc.dg/tree-ssa/pr110269.c: New testcase.
[Bug c/110277] RISC-V: ICE when build RVV intrinsic float reduction with "-march=rv32gc_zve64d -mabi=ilp32d", both GCC 14 and 13.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110277 --- Comment #1 from Li Pan --- Meanwhile, the float reduction for FP16 is not well supported for both the ZVE64 and ZVE32. We will try to fix them together with this bug.
[Bug tree-optimization/110278] New: [14 Regression] FAIL: gcc.dg/tree-ssa/pr103257-1.c scan-tree-dump-times optimized "link_error" 0 from r14-1880-g827e208fa64771
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110278 Bug ID: 110278 Summary: [14 Regression] FAIL: gcc.dg/tree-ssa/pr103257-1.c scan-tree-dump-times optimized "link_error" 0 from r14-1880-g827e208fa64771 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- r14-1880-g827e208fa64771 causes FAIL: gcc.dg/tree-ssa/pr103257-1.c scan-tree-dump-times optimized "link_error" 0 because we now fold more in .original: - if (a ((unsigned int) ((0, 1) && b != 0) > b, (int) (short int) c) != 0) + if (a ((unsigned int) (b != 0) > b, (int) (short int) c) != 0) the call to link_error was optimized away in threadfull1 before this change, after the change code is straight-line and no jump threading opportunity is realized. Before we enter threadfull1 with [local count: 1073741824]: c.0_1 = c; b.2_2 = b; if (b.2_2 != 0) goto ; [50.00%] else goto ; [50.00%] [local count: 536870913]: [local count: 1073741824]: # iftmp.1_5 = PHI <1(2), 0(3)> iftmp.3_3 = (unsigned int) iftmp.1_5; _4 = b.2_2 < iftmp.3_3; e.5_10 = (unsigned short) _4; f.6_11 = (unsigned short) c.0_1; _12 = e.5_10 * f.6_11; if (_12 != 0) goto ; [33.00%] else goto ; [67.00%] [local count: 354334800]: link_error (); [local count: 1073741824]: c = 0; return 0; but afterwards the b != 0 condition is in straight-line code: [local count: 1073741824]: c.0_1 = c; b.1_2 = b; _3 = b.1_2 != 0; _4 = (unsigned int) _3; _5 = b.1_2 < _4; e.3_10 = (unsigned short) _5; f.4_11 = (unsigned short) c.0_1; _12 = e.3_10 * f.4_11; if (_12 != 0) goto ; [33.00%] else goto ; [67.00%] [local count: 354334800]: link_error (); [local count: 1073741824]: c = 0; return 0;
[Bug tree-optimization/110278] [14 Regression] FAIL: gcc.dg/tree-ssa/pr103257-1.c scan-tree-dump-times optimized "link_error" 0 from r14-1880-g827e208fa64771
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110278 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Target Milestone|--- |14.0 Blocks||110269 Known to work||13.1.0 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110269 [Bug 110269] [13 Regression] Missed Dead Code Elimination when using __builtin_unreachable since r13-4607-g2dc5d6b1e7e
[Bug tree-optimization/110279] New: Regressions on aarch64 cause by handing FMA in reassoc (510.parest_r, 508.namd_r)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110279 Bug ID: 110279 Summary: Regressions on aarch64 cause by handing FMA in reassoc (510.parest_r, 508.namd_r) Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: dizhao at os dot amperecomputing.com Target Milestone: --- Created attachment 55339 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55339&action=edit [PATCH] Check for nested FMA chains in reassoc After testing the recent patch "Handle FMA friendly in reassoc pass" (e5405f06) on some of our aarch64 machines, I found regressions in a few spec2017 fprate cases. On ampere1, the patch introduced approximately 2% regression in 510.parest_r. Additionally, with fp_reassoc_width changed so that reassociation actually works on floating points additions (which brings about 1% overall benefit), there's approximately 5% regression in 508.namd_r on ampere1, and 2.6% on neoverse-n1. The compile options we used is "-Ofast -mcpu=ampere1 -flto=32 --param avoid-fma-max-bits=512" for ampere1, and "-Ofast -mcpu=neoverse-n1 -flto=32" for neoverse-n1. The tests are single copy run. Below is from my investigations. 1) From perf result, the regression in 510.parest_r is because the re-arranging in rank_ops_for_fma() produced 2 FMAs in a small loop, with the last FMA's result fed back into first one from PHI. With avoid-fma-max-bits, these candidates are dropped in widening_mul, causing 2% regression; without the parameter there is 1% regression. Before the patch, the generated code looks like: label: fmul v2, v2, v3 fmla v2, v4, v5 fadd v1, v1, v2 ... b.ne label After the patch (without avoid-fma-max-bits): label: ... fmla v1, v2, v3 fmla v1, v4, v5 ... b.ne label 2) As for 508.namd_r, there are slightly fewer FMAs generated. It seems the patch is not handling FMAs like ((a * b + c) * d + e) *... well. For example, below is a piece of CFG before reassoc2: _797 = A_788 * _796; fast_c = _797 + _1161; _815 = diffa * fast_d; _816 = fast_c + _815; _817 = diffa * _816; fast_dir = fast_b + _817; Before the patch, optimized code looks like: fast_c = .FNMA (B_790, _798, _334); _816 = .FMA (diffa, fast_d, fast_c); fast_dir = .FMA (diffa, _816, fast_b); After the patch: _815 = diffa * fast_d; _5910 = .FMA (A_788, _796, _815); _816 = _5909 + _5910; _817 = diffa * _816; _5908 = .FMA (A_788, _801, _817); fast_dir = _5907 + _5908; I came out with a patch to solve this. I'll also attach here.
[Bug bootstrap/110275] [14 Regression] trunk fails to build with binutils trunk on riscv64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110275 Richard Biener changed: What|Removed |Added Target Milestone|--- |14.0 Version|unknown |14.0
[Bug ipa/110276] [13/14 Regression] ICE building efibootguard on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110276 Richard Biener changed: What|Removed |Added Version|unknown |13.1.1 Priority|P3 |P2 Target Milestone|--- |13.2 Summary|[13 Regression] ICE |[13/14 Regression] ICE |building efibootguard on|building efibootguard on |x86_64-linux-gnu|x86_64-linux-gnu Last reconfirmed||2023-06-16 Ever confirmed|0 |1 CC||jamborm at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #1 from Richard Biener --- Huh, I could swear we had a duplicate ... Confirmed on trunk.
[Bug target/110273] i686-w64-mingw32 with -march=znver4 generates AVX instructions without stack alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110273
--- Comment #4 from Alexander Monakov ---
Further reduced:
void f()
{
int c[4] = { 0, 0, 0, 0 };
int cc[8] = { 0 };
asm("" :: "m"(c), "m"(cc));
}
Also reproducible with -march=skylake-avx512 or even plain -mavx512f,
retitling.
[Bug c/110280] New: internal compiler error: in const_unop, at fold-const.cc:1884
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110280 Bug ID: 110280 Summary: internal compiler error: in const_unop, at fold-const.cc:1884 Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: malat at debian dot org Target Milestone: --- I cannot compile highway on arm64 with gcc-13. Compilation fails with: % /usr/bin/g++-13 -freport-bug -DHWY_SHARED_DEFINE -I"/home/malat/arm64/highway-1.0.5~git20230612.46fb57d" -g -O2 -ffile-prefix-map=/home/malat/arm64/highway-1.0.5~git20230612.46fb57d=. -fstack-protector-strong -Wformat -Werror=format-security -DHWY_BROKEN_EMU128=0 -Wdate-time -D_FORTIFY_SOURCE=2 -fPIE -fvisibility=hidden -fvisibility-inlines-hidden -Wno-builtin-macro-redefined -D__DATE__=\"redacted\" -D__TIMESTAMP__=\"redacted\" -D__TIME__=\"redacted\" -fmerge-all-constants -Wall -Wextra -Wconversion -Wsign-conversion -Wvla -Wnon-virtual-dtor -fmath-errno -fno-exceptions -Werror -DHWY_IS_TEST=1 -DGTEST_HAS_PTHREAD=1 -MD -MT CMakeFiles/swizzle_test.dir/hwy/tests/swizzle_test.cc.o -MF CMakeFiles/swizzle_test.dir/hwy/tests/swizzle_test.cc.o.d -o CMakeFiles/swizzle_test.dir/hwy/tests/swizzle_test.cc.o -c '/home/malat/arm64/highway-1.0.5~git20230612.46fb57d/hwy/tests/swizzle_test.cc' during GIMPLE pass: fre /home/malat/arm64/highway-1.0.5~git20230612.46fb57d/hwy/tests/swizzle_test.cc: In static member function 'static void hwy::N_SVE::TestPer4LaneBlockShuffle::TestTblLookupPer4LaneBlkShuf(D, size_t, hwy::N_SVE::TFromD*, hwy::N_SVE::TFromD*) [with D = hwy::N_SVE::Simd]': /home/malat/arm64/highway-1.0.5~git20230612.46fb57d/hwy/tests/swizzle_test.cc:787:1: internal compiler error: in const_unop, at fold-const.cc:1884 787 | } // namespace hwy | ^ 0xcd88f7 const_unop(tree_code, tree_node*, tree_node*) ../../src/gcc/fold-const.cc:1884 0xdfbadb gimple_resimplify1 ../../src/gcc/gimple-match-head.cc:214 0xdcbee3 gimple_simplify(gimple*, gimple_match_op*, gimple**, tree_node* (*)(tree_node*), tree_node* (*)(tree_node*)) ../../src/gcc/gimple-match-head.cc:1115 0xfdec5f gimple_fold_stmt_to_constant_1(gimple*, tree_node* (*)(tree_node*), tree_node* (*)(tree_node*)) ../../src/gcc/gimple-fold.cc:7444 0xfdc88f try_to_simplify ../../src/gcc/tree-ssa-sccvn.cc:6076 0xfdc88f visit_stmt ../../src/gcc/tree-ssa-sccvn.cc:6119 0xfd6d9f process_bb ../../src/gcc/tree-ssa-sccvn.cc:7925 0xfcc1ff do_rpo_vn_1 ../../src/gcc/tree-ssa-sccvn.cc:8411 0x108dedb execute ../../src/gcc/tree-ssa-sccvn.cc:8683 Please submit a full bug report, with preprocessed source. Please include the complete backtrace with any bug report. See for instructions. Preprocessed source stored into /tmp/ccLfBeeb.out file, please attach this to your bugreport.
[Bug tree-optimization/110279] [14 Regression] Regressions on aarch64 cause by handing FMA in reassoc (510.parest_r, 508.namd_r)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110279 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Target Milestone|--- |14.0 Summary|Regressions on aarch64 |[14 Regression] Regressions |cause by handing FMA in |on aarch64 cause by handing |reassoc (510.parest_r, |FMA in reassoc |508.namd_r) |(510.parest_r, 508.namd_r) Target||aarch64
[Bug c/110280] internal compiler error: in const_unop, at fold-const.cc:1884
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110280 --- Comment #1 from Mathieu Malaterre --- Created attachment 55340 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55340&action=edit preprocessed source
[Bug middle-end/109766] Passing doubles through the stack generates a stack adjustment per each such argument at -Os/-Oz.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109766 --- Comment #3 from Roger Sayle --- For the record a solution was proposed at https://gcc.gnu.org/pipermail/gcc-patches/2023-May/618197.html but this approach failed review at https://gcc.gnu.org/pipermail/gcc-patches/2023-May/618278.html
[Bug target/110280] internal compiler error: in const_unop, at fold-const.cc:1884
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110280 ktkachov at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 CC||ktkachov at gcc dot gnu.org Last reconfirmed||2023-06-16 Status|UNCONFIRMED |NEW Target|arm64 |aarch64 --- Comment #2 from ktkachov at gcc dot gnu.org --- Confirmed, reducing.
[Bug tree-optimization/110278] [14 Regression] FAIL: gcc.dg/tree-ssa/pr103257-1.c scan-tree-dump-times optimized "link_error" 0 from r14-1880-g827e208fa64771
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110278 Richard Biener changed: What|Removed |Added CC||pinskia at gcc dot gnu.org --- Comment #1 from Richard Biener --- So looks like we're missing simplification of uns < (typeof uns)(uns != 0) which we managed to prove is false. When uns != 0 then this is uns < 1 which is false so uns == 0 but then uns < 0 is also false.
[Bug tree-optimization/110278] [14 Regression] FAIL: gcc.dg/tree-ssa/pr103257-1.c scan-tree-dump-times optimized "link_error" 0 from r14-1880-g827e208fa64771
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110278 --- Comment #2 from Richard Biener --- And x != (typeof x)(x == 0) is always true, the only other related one I could come up with. That's optimized for _Bool but not integer types.
[Bug tree-optimization/110278] [14 Regression] FAIL: gcc.dg/tree-ssa/pr103257-1.c scan-tree-dump-times optimized "link_error" 0 from r14-1880-g827e208fa64771
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110278 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-06-16 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #3 from Richard Biener --- Mine.
[Bug c/110281] New: wrong code with '-O3'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110281 Bug ID: 110281 Summary: wrong code with '-O3' Product: gcc Version: 11.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: 19373742 at buaa dot edu.cn Target Milestone: --- Created attachment 55341 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55341&action=edit The preprocessed file *** OS and Platform: CentOS Linux release 7.9.2009 (Core), x86_64 GNU/Linux *** gcc version: # /home/gcc-releases/gcc-11-0615/bin/gcc -v Using built-in specs. COLLECT_GCC=/home/gcc-releases/gcc-11-0615/bin/gcc COLLECT_LTO_WRAPPER=/home/gcc-releases/gcc-11-0615/libexec/gcc/x86_64-pc-linux-gnu/11.4.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ./configure --prefix=/home/gcc-releases/gcc-11-0615/ --disable-multilib --enable-languages=c,c++ Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 11.4.1 20230615 (GCC) *** Command Lines: /home/gcc-releases/gcc-11-0615/bin/gcc -I /home/csmith_record/include/csmith-2.3.0/ -O3 -fno-aggressive-loop-optimizations -fno-align-functions -fno-align-jumps -fno-align-labels -fno-align-loops -fno-allocation-dce -fno-asynchronous-unwind-tables -fno-auto-inc-dec -fno-bit-tests -fno-branch-count-reg -fno-caller-saves -fno-code-hoisting -fno-combine-stack-adjustments -fno-compare-elim -fno-cprop-registers -fno-crossjumping -fno-cse-follow-jumps -fno-dce -fno-defer-pop -fno-delete-null-pointer-checks -fno-devirtualize -fno-devirtualize-speculatively -fno-dse -fno-early-inlining -fno-expensive-optimizations -fno-forward-propagate -fno-fp-int-builtin-inexact -fno-function-cse -fno-gcse -fno-gcse-after-reload -fno-gcse-lm -fno-guess-branch-probability -fno-hoist-adjacent-loads -fno-if-conversion -fno-if-conversion2 -fno-indirect-inlining -fno-inline -fno-inline-atomics -fno-inline-functions -fno-inline-functions-called-once -fno-inline-small-functions -fno-ipa-bit-cp -fno-ipa-cp -fno-ipa-cp-clone -fno-ipa-icf -fno-ipa-icf-functions -fno-ipa-icf-variables -fno-ipa-modref -fno-ipa-profile -fno-ipa-pure-const -fno-ipa-ra -fno-ipa-reference -fno-ipa-reference-addressable -fno-ipa-sra -fno-ipa-stack-alignment -fno-ipa-vrp -fno-ira-hoist-pressure -fno-ira-share-save-slots -fno-ira-share-spill-slots -fno-isolate-erroneous-paths-dereference -fno-ivopts -fno-jump-tables -fno-lifetime-dse -fno-loop-interchange -fno-loop-unroll-and-jam -fno-lra-remat -fno-math-errno -fno-move-loop-invariants -fno-omit-frame-pointer -fno-optimize-sibling-calls -fno-optimize-strlen -fno-partial-inlining -fno-peel-loops -fno-peephole -fno-peephole2 -fno-plt -fno-predictive-commoning -fno-prefetch-loop-arrays -fno-printf-return-value -fno-ree -fno-reg-struct-return -fno-rename-registers -fno-reorder-blocks -fno-reorder-blocks-and-partition -fno-reorder-functions -fno-rerun-cse-after-loop -fno-sched-critical-path-heuristic -fno-sched-dep-count-heuristic -fno-sched-group-heuristic -fno-sched-interblock -fno-sched-last-insn-heuristic -fno-sched-rank-heuristic -fno-sched-spec -fno-sched-spec-insn-heuristic -fno-sched-stalled-insns-dep -fno-schedule-fusion -fno-schedule-insns2 -fno-short-enums -fno-shrink-wrap -fno-shrink-wrap-separate -fno-signed-zeros -fno-split-ivs-in-unroller -fno-split-loops -fno-split-paths -fno-split-wide-types -fno-ssa-backprop -fno-ssa-phiopt -fno-stdarg-opt -fno-store-merging -fno-strict-aliasing -fno-strict-volatile-bitfields -fno-thread-jumps -fno-toplevel-reorder -fno-trapping-math -fno-tree-bit-ccp -fno-tree-builtin-call-dce -fno-tree-ccp -fno-tree-ch -fno-tree-coalesce-vars -fno-tree-copy-prop -fno-tree-cselim -fno-tree-dce -fno-tree-dominator-opts -fno-tree-dse -fno-tree-forwprop -fno-tree-fre -fno-tree-loop-distribute-patterns -fno-tree-loop-distribution -fno-tree-loop-if-convert -fno-tree-loop-im -fno-tree-loop-ivcanon -fno-tree-loop-optimize -fno-tree-loop-vectorize -fno-tree-partial-pre -fno-tree-phiprop -fno-tree-pre -fno-tree-pta -fno-tree-reassoc -fno-tree-scev-cprop -fno-tree-sink -fno-tree-slp-vectorize -fno-tree-slsr -fno-tree-sra -fno-tree-switch-conversion -fno-tree-tail-merge -fno-tree-ter -fno-tree-vrp -fno-unroll-completely-grow-size -fno-unswitch-loops -fno-unwind-tables -fno-var-tracking -fno-var-tracking-assignments -fno-version-loops-for-strides -fno-web -faggressive-loop-optimizations -fno-align-functions -fno-align-jumps -falign-labels -fno-align-loops -fno-allocation-dce -fasynchronous-unwind-tables -fauto-inc-dec -fbit-tests -fno-branch-count-reg -fno-caller-saves -fno-code-hoisting -fcombine-stack-adjustments -fcompare-elim -fno-cprop-registers -fcrossjumping -fcse-follow-jumps -fdce -fno-def
[Bug c/110281] wrong code with '-O3'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110281 --- Comment #1 from CTC <19373742 at buaa dot edu.cn> --- Created attachment 55342 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55342&action=edit The compiler output
[Bug tree-optimization/110219] [14 Regression] ICE: tree check: expected integer_cst, have real_cst in to_wide, at tree.h:6314 with _Complex float to int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110219 --- Comment #2 from Zdenek Sojka --- This seems to have been fixed between r14-1822 (BAD) and r14-1881 (GOOD).
[Bug middle-end/110281] wrong code with '-O3'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110281 Richard Biener changed: What|Removed |Added Known to fail||10.4.1, 11.3.0, 12.2.1, ||13.1.1, 14.0 Keywords||wrong-code Target||x86_64-*-* Component|c |middle-end --- Comment #2 from Richard Biener --- I can confirm a different checksum with GCC 10, 11, 12, 13 and trunk -O2 vs. -O[01]
[Bug middle-end/110281] wrong code with '-O3'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110281 --- Comment #3 from Richard Biener --- -fno-strict-aliasing avoids the issue.
[Bug middle-end/110281] wrong code with '-O3'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110281 --- Comment #4 from Richard Biener --- clang produces the same behavior
[Bug c/110282] New: Segmentation fault with specific optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110282 Bug ID: 110282 Summary: Segmentation fault with specific optimizations Product: gcc Version: 11.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: 19373742 at buaa dot edu.cn Target Milestone: --- Created attachment 55343 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55343&action=edit The preprocessed file *** OS and Platform: CentOS Linux release 7.9.2009 (Core), x86_64 GNU/Linux *** gcc version: # /home/gcc-releases/gcc-11-0615/bin/gcc -v Using built-in specs. COLLECT_GCC=/home/gcc-releases/gcc-11-0615/bin/gcc COLLECT_LTO_WRAPPER=/home/gcc-releases/gcc-11-0615/libexec/gcc/x86_64-pc-linux-gnu/11.4.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ./configure --prefix=/home/gcc-releases/gcc-11-0615/ --disable-multilib --enable-languages=c,c++ Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 11.4.1 20230615 (GCC) *** Command Lines: /home/gcc-releases/gcc-11-0615/bin/gcc -I /home/csmith_record/include/csmith-2.3.0/ -O3 -fno-aggressive-loop-optimizations -fno-align-functions -fno-align-jumps -fno-align-labels -fno-align-loops -fno-allocation-dce -fno-asynchronous-unwind-tables -fno-auto-inc-dec -fno-bit-tests -fno-branch-count-reg -fno-caller-saves -fno-code-hoisting -fno-combine-stack-adjustments -fno-compare-elim -fno-cprop-registers -fno-crossjumping -fno-cse-follow-jumps -fno-dce -fno-defer-pop -fno-delete-null-pointer-checks -fno-devirtualize -fno-devirtualize-speculatively -fno-dse -fno-early-inlining -fno-expensive-optimizations -fno-forward-propagate -fno-fp-int-builtin-inexact -fno-function-cse -fno-gcse -fno-gcse-after-reload -fno-gcse-lm -fno-guess-branch-probability -fno-hoist-adjacent-loads -fno-if-conversion -fno-if-conversion2 -fno-indirect-inlining -fno-inline -fno-inline-atomics -fno-inline-functions -fno-inline-functions-called-once -fno-inline-small-functions -fno-ipa-bit-cp -fno-ipa-cp -fno-ipa-cp-clone -fno-ipa-icf -fno-ipa-icf-functions -fno-ipa-icf-variables -fno-ipa-modref -fno-ipa-profile -fno-ipa-pure-const -fno-ipa-ra -fno-ipa-reference -fno-ipa-reference-addressable -fno-ipa-sra -fno-ipa-stack-alignment -fno-ipa-vrp -fno-ira-hoist-pressure -fno-ira-share-save-slots -fno-ira-share-spill-slots -fno-isolate-erroneous-paths-dereference -fno-ivopts -fno-jump-tables -fno-lifetime-dse -fno-loop-interchange -fno-loop-unroll-and-jam -fno-lra-remat -fno-math-errno -fno-move-loop-invariants -fno-omit-frame-pointer -fno-optimize-sibling-calls -fno-optimize-strlen -fno-partial-inlining -fno-peel-loops -fno-peephole -fno-peephole2 -fno-plt -fno-predictive-commoning -fno-prefetch-loop-arrays -fno-printf-return-value -fno-ree -fno-reg-struct-return -fno-rename-registers -fno-reorder-blocks -fno-reorder-blocks-and-partition -fno-reorder-functions -fno-rerun-cse-after-loop -fno-sched-critical-path-heuristic -fno-sched-dep-count-heuristic -fno-sched-group-heuristic -fno-sched-interblock -fno-sched-last-insn-heuristic -fno-sched-rank-heuristic -fno-sched-spec -fno-sched-spec-insn-heuristic -fno-sched-stalled-insns-dep -fno-schedule-fusion -fno-schedule-insns2 -fno-short-enums -fno-shrink-wrap -fno-shrink-wrap-separate -fno-signed-zeros -fno-split-ivs-in-unroller -fno-split-loops -fno-split-paths -fno-split-wide-types -fno-ssa-backprop -fno-ssa-phiopt -fno-stdarg-opt -fno-store-merging -fno-strict-aliasing -fno-strict-volatile-bitfields -fno-thread-jumps -fno-toplevel-reorder -fno-trapping-math -fno-tree-bit-ccp -fno-tree-builtin-call-dce -fno-tree-ccp -fno-tree-ch -fno-tree-coalesce-vars -fno-tree-copy-prop -fno-tree-cselim -fno-tree-dce -fno-tree-dominator-opts -fno-tree-dse -fno-tree-forwprop -fno-tree-fre -fno-tree-loop-distribute-patterns -fno-tree-loop-distribution -fno-tree-loop-if-convert -fno-tree-loop-im -fno-tree-loop-ivcanon -fno-tree-loop-optimize -fno-tree-loop-vectorize -fno-tree-partial-pre -fno-tree-phiprop -fno-tree-pre -fno-tree-pta -fno-tree-reassoc -fno-tree-scev-cprop -fno-tree-sink -fno-tree-slp-vectorize -fno-tree-slsr -fno-tree-sra -fno-tree-switch-conversion -fno-tree-tail-merge -fno-tree-ter -fno-tree-vrp -fno-unroll-completely-grow-size -fno-unswitch-loops -fno-unwind-tables -fno-var-tracking -fno-var-tracking-assignments -fno-version-loops-for-strides -fno-web -faggressive-loop-optimizations -fno-align-functions -fno-align-jumps -fno-align-labels -fno-align-loops -fallocation-dce -fasynchronous-unwind-tables -fauto-inc-dec -fbit-tests -fbranch-count-reg -fno-caller-saves -fno-code-hoisting -fcombine-stack-adjustments -fcompare-elim -fno-cprop-registers -fno-crossjumping -fno-c
[Bug c/110282] Segmentation fault with specific optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110282 --- Comment #1 from CTC <19373742 at buaa dot edu.cn> --- Created attachment 55344 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55344&action=edit The compiler output
[Bug middle-end/110281] wrong code with '-O3'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110281 --- Comment #5 from CTC <19373742 at buaa dot edu.cn> --- Could you please do me a favor to confirm whether this phenomenon indicates a bug or a normal behavior? Actually, I also found other optimization sequences with -fstrict-aliasing which output 'checksum = 85C697B'. Thanks very much for your efforts in advance!
[Bug middle-end/110281] wrong code with '-O3'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110281 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- That requires detailed analysis nobody performed yet. csmith is known to generate invalid programs sometimes, especially with some options, and only such analysis can give definite answers. Though, two independent compilers behaving the same and -fno-strict-aliasing option making it go away is a strong indication it could very well be a bug in the generated testcase.
[Bug middle-end/110281] wrong code with '-O3'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110281 --- Comment #7 from CTC <19373742 at buaa dot edu.cn> --- (In reply to Jakub Jelinek from comment #6) > That requires detailed analysis nobody performed yet. csmith is known to > generate invalid programs sometimes, especially with some options, and only > such analysis can give definite answers. Though, two independent compilers > behaving the same and -fno-strict-aliasing option making it go away is a > strong indication it could very well be a bug in the generated testcase. Thanks very much for your explanation!
[Bug tree-optimization/110243] [13/14 Regression] Wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110243 --- Comment #2 from Richard Biener --- [local count: 5636687]: + _141 = (int) _5; + _144 = _141 * 2; + ivtmp.22_136 = (unsigned int) _144; ... [local count: 51242611]: - # d.7_1 = PHI <0(26), _48(23)> + # ivtmp.22_17 = PHI ... - _45 = d.7_1 + 3194967297; - _46 = _44 + _45; + _46 = ivtmp.22_17 + 2094967296; that signed multiplication by two smells like it could be an issue. Keeping IVOPTs enabled works when disabling the followup DOM and VRP passes who eventually produce range info. IV struct: SSA_NAME: _46 Type: unsigned int Base: (unsigned int) (((int) _5 + -1) + ((int) _5 + -11)) + 3194967297 Step: 1 Biv: N Candidate 5: Var befor: ivtmp.22 Var after: ivtmp.22 Incr POS: before exit test IV struct: Type: unsigned int Base: (unsigned int) ((int) _5 * 2) Step: 1 Biv:N Overflowness wrto loop niter: Overflow and indeed (int) _5 * 2 will overflow as _5 is 'X'. This multiplication is built via #0 0x010eaa2a in fold_build2_loc (loc=0, code=MULT_EXPR, type=, op0=, op1=) at /home/rguenther/src/trunk/gcc/fold-const.cc:13781 #1 0x02e41e72 in generic_simplify_PLUS_EXPR (loc=0, code=PLUS_EXPR, type=, _p0=, _p1=) at generic-match-2.cc:4924 #2 0x01edc488 in generic_simplify (loc=0, code=PLUS_EXPR, type=, _p0=, _p1=) at generic-match-5.cc:8173 #3 0x010dbf1a in fold_binary_loc (loc=0, code=PLUS_EXPR, type=, op0=, op1=) at /home/rguenther/src/trunk/gcc/fold-const.cc:10889 #4 0x010eaa03 in fold_build2_loc (loc=0, code=PLUS_EXPR, type=, op0=, op1=) at /home/rguenther/src/trunk/gcc/fold-const.cc:13779 #5 0x0180266d in strip_offset_1 (expr=, inside_addr=false, top_compref=false, offset=0x7fffd628) at /home/rguenther/src/trunk/gcc/tree-ssa-loop-ivopts.cc:2822 #6 0x018024f7 in strip_offset_1 (expr=, inside_addr=false, top_compref=false, offset=0x7fffd6d0) at /home/rguenther/src/trunk/gcc/tree-ssa-loop-ivopts.cc:2804 #7 0x01802e70 in strip_offset (expr=, offset=0x7fffd728) at /home/rguenther/src/trunk/gcc/tree-ssa-loop-ivopts.cc:2949 #8 0x01804d7e in add_iv_candidate_for_use (data=0x7fffd990, use=0x4207f60) at /home/rguenther/src/trunk/gcc/tree-ssa-loop-ivopts.cc:3566 where strip_offset simplifies (unsigned int) (((int) _5 + -1) + ((int) _5 + -11)) + 3194967297 to this expression and an offset. I think IVOPTs strip_offset suffers from the same issues as tree-data-ref.cc split_constant_offset did. Using split_constant_offset instead does not produce this candidate. Instead we have Candidate 4: Var befor: ivtmp.21 Var after: ivtmp.21 Incr POS: before exit test IV struct: Type: unsigned int Base: (unsigned int) (((int) _5 + -1) + ((int) _5 + -11)) + 3194967297 Step: 1 Biv:N Overflowness wrto loop niter: Overflow Candidate 5: Var befor: ivtmp.22 Var after: ivtmp.22 Incr POS: before exit test IV struct: Type: unsigned int Base: (unsigned int) _5 + 3194967298 Step: 1 Biv:N Overflowness wrto loop niter: Overflow and Selected IV set for loop 3 at t.c:16, 9 avg niters, 1 IVs: Candidate 5: Var befor: ivtmp.22_17 Var after: ivtmp.22_16 Incr POS: before exit test IV struct: Type: unsigned int Base: (unsigned int) _5 + 3194967298 Step: 1 Biv:N Overflowness wrto loop niter: Overflow
[Bug tree-optimization/110243] [13/14 Regression] Wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110243 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #3 from Richard Biener --- I'm testing a fix.
[Bug tree-optimization/110278] [14 Regression] FAIL: gcc.dg/tree-ssa/pr103257-1.c scan-tree-dump-times optimized "link_error" 0 from r14-1880-g827e208fa64771
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110278 --- Comment #4 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:69b04fe7445c88edafd6983e28353a158e4314b5 commit r14-1883-g69b04fe7445c88edafd6983e28353a158e4314b5 Author: Richard Biener Date: Fri Jun 16 11:47:45 2023 +0200 tree-optimization/110278 - uns < (typeof uns)(uns != 0) is always false The following adds two patterns simplifying comparisons, uns < (typeof uns)(uns != 0) is always false and x != (typeof x)(x == 0) is always true. PR tree-optimization/110278 * match.pd (uns < (typeof uns)(uns != 0) -> false): New. (x != (typeof x)(x == 0) -> true): Likewise.
[Bug tree-optimization/110269] [13 Regression] Missed Dead Code Elimination when using __builtin_unreachable since r13-4607-g2dc5d6b1e7e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110269 Bug 110269 depends on bug 110278, which changed state. Bug 110278 Summary: [14 Regression] FAIL: gcc.dg/tree-ssa/pr103257-1.c scan-tree-dump-times optimized "link_error" 0 from r14-1880-g827e208fa64771 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110278 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/110278] [14 Regression] FAIL: gcc.dg/tree-ssa/pr103257-1.c scan-tree-dump-times optimized "link_error" 0 from r14-1880-g827e208fa64771
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110278 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Richard Biener --- Fixed.
[Bug target/104024] ICE in curr_insn_transform with -O1 -mpower10-fusion -mpower10-fusion-2logical with __int128_t and __builtin_add_overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104024 --- Comment #6 from Kewen Lin --- (In reply to Martin Jambor from comment #5) > I have just seen a similar ICE with a ppc64le cross-compiler. Running > > ~/cross/bin/ppc64le-linux-gnu-gcc > /home/worker/buildworker/tiber-option-juggler/build/gcc/testsuite/c-c++- > common/torture/builtin-arith-overflow-p-6.c -mpower10-fusion -mno-vsx -Og > > (where the input comes from our testcase but the options are of course > invented) results in ICE in in curr_insn_transform, at > lra-constraints.cc:4231. Is this the same issue or should I file a new bug? I believe it's due to the same root cause, -mcpu=power6 doesn't enable any vsx features (like -mno-vsx), you don't need to open a new one. :)
[Bug c++/110283] New: Bogus Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110283
Bug ID: 110283
Summary: Bogus Warray-bounds
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: pilarlatiesa at gmail dot com
Target Milestone: ---
$ ~/gcc-13/bin/g++ -v
Usando especificaciones internas.
COLLECT_GCC=~/gcc-13/bin/g++
COLLECT_LTO_WRAPPER=/home/pililatiesa/gcc-13/libexec/gcc/x86_64-pc-linux-gnu/13.1.0/lto-wrapper
Objetivo: x86_64-pc-linux-gnu
Configurado con: ../gcc-13.1.0/configure --enable-languages=c,c++
--disable-multilib --prefix=/home/pililatiesa/gcc-13/
Modelo de hilos: posix
Algoritmos de compresión LTO admitidos: zlib
gcc versión 13.1.0 (GCC)
$ ~/gcc-13/bin/g++ -std=c++23 -Wall -O3 -c ElemBase.ii
En el fichero incluido desde ../../MEF/ElemBase.h:11,
desde ../ElemBase.cpp:2:
In member function ‘constexpr const std::array<_Tp, _Nm>::value_type&
std::array<_Tp, _Nm>::operator[](size_type) const [with _Tp = const TNodo<3>*;
long unsigned int _Nm = 2]’,
inlined from ‘const TNodo::Ngdl>&
TElemBase::Nodo(int) const [with TElem = TElemViga]’ at
../../MEF/ElemBase.h:64:25,
inlined from ‘void TElemBase::CalcCCTerm(TTripletVec&) const [with
TElem = TElemViga]’ at ../ElemBase.cpp:10:21:
/home/pililatiesa/gcc-13/include/c++/13.1.0/array:213:17: aviso: el subíndice 2
de la matriz está por encima de los límites de matriz de
‘std::__array_traits*, 2>::_Type’ {aka ‘const TNodo<3>* const
[2]’} [-Warray-bounds=]
/home/pililatiesa/gcc-13/include/c++/13.1.0/array: In member function ‘void
TElemBase::CalcCCTerm(TTripletVec&) const [with TElem = TElemViga]’:
/home/pililatiesa/gcc-13/include/c++/13.1.0/array:109:48: nota: while
referencing ‘std::array*, 2>::_M_elems’
I couldn't get rid of the eigen dependency, sorry.
It only happens with O3.
It appears that it is only a bogus warning, but I don't know if wrong code is
actually generated.
[Bug c++/110283] Bogus Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110283 --- Comment #1 from Pilar Latiesa --- Created attachment 55345 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55345&action=edit preprocessed code
[Bug tree-optimization/110062] missed vectorization in graphicsmagick
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110062
--- Comment #6 from Richard Biener ---
Btw, we would also be able to vectorize just the red and green channel:
t.c:18:27: note: * Analysis succeeded with vector mode V4SF
t.c:18:27: note: SLPing BB part
t.c:18:27: note: Costing subgraph:
t.c:18:27: note: node 0x420b6c8 (max_nunits=2, refcnt=1) vector(2) unsigned
char
t.c:18:27: note: op template: q_45(D)->red = _29;
t.c:18:27: note:stmt 0 q_45(D)->red = _29;
t.c:18:27: note:stmt 1 q_45(D)->green = _31;
t.c:18:27: note:children 0x420b750
t.c:18:27: note: node (external) 0x420b750 (max_nunits=2, refcnt=1) vector(2)
unsigned char
t.c:18:27: note:stmt 0 _29 = (unsigned char) pixel$red_78;
t.c:18:27: note:stmt 1 _31 = (unsigned char) pixel$green_84;
t.c:18:27: note:children 0x420b7d8
t.c:18:27: note: node 0x420b7d8 (max_nunits=2, refcnt=1) vector(2) float
t.c:18:27: note: op template: pixel$red_78 = PHI <_142(11),
pixel$red_60(D)(10)>
t.c:18:27: note:stmt 0 pixel$red_78 = PHI <_142(11),
pixel$red_60(D)(10)>
t.c:18:27: note:stmt 1 pixel$green_84 = PHI <_144(11),
pixel$green_61(D)(10)>
t.c:18:27: note:children 0x420b860 0x420be38
t.c:18:27: note: node 0x420b860 (max_nunits=2, refcnt=1) vector(2) float
t.c:18:27: note: op template: _142 = PHI <_143(4)>
t.c:18:27: note:stmt 0 _142 = PHI <_143(4)>
t.c:18:27: note:stmt 1 _144 = PHI <_145(4)>
t.c:18:27: note:children 0x420b8e8
t.c:18:27: note: node 0x420b8e8 (max_nunits=2, refcnt=2) vector(2) float
t.c:18:27: note: op template: _143 = PHI <_12(3)>
t.c:18:27: note:stmt 0 _143 = PHI <_12(3)>
t.c:18:27: note:stmt 1 _145 = PHI <_17(3)>
t.c:18:27: note:children 0x420b970
t.c:18:27: note: node 0x420b970 (max_nunits=2, refcnt=2) vector(2) float
t.c:18:27: note: op template: _12 = _11 + pixel$red_80;
t.c:18:27: note:stmt 0 _12 = _11 + pixel$red_80;
t.c:18:27: note:stmt 1 _17 = _16 + pixel$green_82;
t.c:18:27: note:children 0x420b9f8 0x420bca0
t.c:18:27: note: node 0x420b9f8 (max_nunits=2, refcnt=1) vector(2) float
t.c:18:27: note: op template: _11 = _4 * _10;
t.c:18:27: note:stmt 0 _11 = _4 * _10;
t.c:18:27: note:stmt 1 _16 = _4 * _15;
t.c:18:27: note:children 0x420ba80 0x420bb08
t.c:18:27: note: node (external) 0x420ba80 (max_nunits=1, refcnt=1) vector(2)
float
t.c:18:27: note:{ _4, _4 }
t.c:18:27: note: node 0x420bb08 (max_nunits=2, refcnt=1) vector(2) float
t.c:18:27: note: op template: _10 = (float) _9;
t.c:18:27: note:stmt 0 _10 = (float) _9;
t.c:18:27: note:stmt 1 _15 = (float) _14;
t.c:18:27: note:children 0x420bb90
t.c:18:27: note: node (external) 0x420bb90 (max_nunits=2, refcnt=1) vector(2)
int
t.c:18:27: note:stmt 0 _9 = (int) _8;
t.c:18:27: note:stmt 1 _14 = (int) _13;
t.c:18:27: note:children 0x420bc18
t.c:18:27: note: node 0x420bc18 (max_nunits=2, refcnt=1) vector(2) unsigned
char
t.c:18:27: note: op template: _8 = _7->red;
t.c:18:27: note:stmt 0 _8 = _7->red;
t.c:18:27: note:stmt 1 _13 = _7->green;
t.c:18:27: note: node 0x420bca0 (max_nunits=2, refcnt=1) vector(2) float
t.c:18:27: note: op template: pixel$red_80 = PHI <_12(9), pixel$red_79(5)>
t.c:18:27: note:stmt 0 pixel$red_80 = PHI <_12(9), pixel$red_79(5)>
t.c:18:27: note:stmt 1 pixel$green_82 = PHI <_17(9), pixel$green_85(5)>
t.c:18:27: note:children 0x420b970 0x420bd28
t.c:18:27: note: node 0x420bd28 (max_nunits=2, refcnt=1) vector(2) float
t.c:18:27: note: op template: pixel$red_79 = PHI <_143(8), pixel$red_60(D)(7)>
t.c:18:27: note:stmt 0 pixel$red_79 = PHI <_143(8), pixel$red_60(D)(7)>
t.c:18:27: note:stmt 1 pixel$green_85 = PHI <_145(8),
pixel$green_61(D)(7)>
t.c:18:27: note:children 0x420b8e8 0x420bdb0
t.c:18:27: note: node (external) 0x420bdb0 (max_nunits=1, refcnt=1) vector(2)
float
t.c:18:27: note:{ pixel$red_60(D), pixel$green_61(D) }
t.c:18:27: note: node (external) 0x420be38 (max_nunits=1, refcnt=1) vector(2)
float
t.c:18:27: note:{ pixel$red_60(D), pixel$green_61(D) }
But the '(external)' show that we're missing support for some operations:
t.c:18:27: note: ==> examining statement: _29 = (unsigned char) pixel$red_78;
t.c:18:27: note: vect_is_simple_use: operand pixel$red_78 = PHI <_142(11),
pixel$red_60(D)(10)>, type of def: internal
t.c:18:27: missed: conversion not supported by target.
t.c:18:27: note: vect_is_simple_use: operand pixel$red_78 = PHI <_142(11),
pixel$red_60(D)(10)>, type of def: internal
t.c:18:27: missed: no optab.
t.c:18:27: missed: not vectorized: relevant stmt not supported: _29 =
(unsigned char) pixel$red_78;
t.c:18:27: note: Building vector operands of 0x4215e90 from scalars instead
that's float -> unsigned char
for the stores:
q->red=pixel.red;
q->green=pixel.green;
we then cut the SLP off from that node,
[Bug modula2/110284] New: [14 Regression] Bootstrap failures with m2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110284 Bug ID: 110284 Summary: [14 Regression] Bootstrap failures with m2 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: modula2 Assignee: gaius at gcc dot gnu.org Reporter: jakub at gcc dot gnu.org Target Milestone: --- As mentioned in https://gcc.gnu.org/pipermail/gcc-patches/2023-June/620819.html and later in https://gcc.gnu.org/pipermail/gcc-patches/2023-June/621576.html since the inclusion of insn-opinit.h (generated header) in internal-fn.h parallel bootstraps with modula2 enabled randomly fail with errors like: In file included from ../../gcc/m2/gm2-gcc/gcc-consolidation.h:74, from ../../gcc/m2/gm2-lang.cc:24: ../../gcc/internal-fn.h:24:10: fatal error: insn-opinit.h: No such file or directory 24 | #include "insn-opinit.h" | ^~~ compilation terminated. (not always, just sometimes with bad luck). My r14-1603-g00bfc503cc3b3e8f3 commit for this was actually incorrect and should be reverted - the problem is that gcc/m2/Make-lang.in is included before generated_files variable is set in gcc/Makefile.in and the order only rule $(GM2_C_OBJS) : | $(generated_files) is then expanded at that point as $(GM2_C_OBJS) : | and so doesn't actually do anything. As I said, the right fix is mentioned in the second mail, -$(GM2_C_OBJS) : | $(generated_files) +m2_OBJS = $(GM2_C_OBJS) should work correctly, because then the $(ALL_HOST_OBJS) : | $(generated_files) rule in gcc/Makefile.in will include the m2 FE files and will DTRT. The problem is that this needs further work on the m2 FE, which I can't easily do because I don't know much about the FE. Inclusion in m2_OBJS means they will be compiled with -DIN_GCC_FRONTEND and e.g. checking in system.h tries to make sure that rtl.h, except.h etc. headers aren't included in the FEs, but m2 FE does include them (not sure why, most of them probably uselessly). There is a further problem that m2 compiles its own variant of stor-layout.cc which is clearly a backend file. If this can't be made to work correctly, I guess as last resort perhaps -$(GM2_C_OBJS) : | $(generated_files) +ALL_HOST_OBJS += $(GM2_C_OBJS) could be used, which would be an ugly hack, but I think putting it in m2_OBJS is the right thing. Gaius, could you please have a look? Thanks.
[Bug modula2/110284] [14 Regression] Bootstrap failures with m2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110284 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |14.0 Priority|P3 |P1
[Bug ipa/110276] [13/14 Regression] ICE building efibootguard on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110276 Martin Jambor changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from Martin Jambor --- Mine
[Bug target/110104] gcc produces sub-optimal code for _addcarry_u64 chain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110104 --- Comment #4 from Mason --- I confirm that trunk now emits the same code for testcase1 and testcase2. Thanks Jakub and Roger, great work!
[Bug target/54089] [SH] Refactor shift patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089 --- Comment #75 from Alexander Klepikov --- I found that patch incorrectly works when '-O0 -fmove-loop-invariants' flags are set. Stock loop optimization passes do not run when '-O0' is specified desipte '-fmove-loop-invariants' is set. I'll do the same and recheck again.
[Bug analyzer/110285] New: -Wanalyzer-infinite-loop false positive.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110285 Bug ID: 110285 Summary: -Wanalyzer-infinite-loop false positive. Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: 080ariel at gmail dot com Target Milestone: --- Created attachment 55346 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55346&action=edit Preprocessed file of a-test1.i -Wanalyzer-infinite-loop reports a false positive in test1.c with -O0 -O1 -O2 but not with -O3. -Wanalyzer-infinite-loop reports a false positive in test2.c only with -O3. Small changes fix the bug or change it from happening only in -O3 to happening only in the others levels and vice-versa. It is why I have not been able to make test2.c minimal while keeping the bug in -O3(it is attached just to show it can also happen in -O3). It does not realize it cannot recurse because the condition to recurse is both condition_to_recurse and !condition_to_recurse. The analyzer report exactly the same thing in 14.0.0 and in 13.1.1. -- Tested both in 13.1.1 and in 14.0.0(commit: b6cb10af12cf869c1ae348c0e5cb2d364ef0abce) in Linux. Options given when GCC was configured/built: ../configure --enable-languages=c Complete command line that triggers the bug: gcc -fanalyzer minimalcase.c
[Bug analyzer/110285] -Wanalyzer-infinite-loop false positive.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110285 --- Comment #1 from Ariel Cabello Mateos <080ariel at gmail dot com> --- Created attachment 55347 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55347&action=edit test1.c
[Bug analyzer/110285] -Wanalyzer-infinite-loop false positive.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110285 --- Comment #2 from Ariel Cabello Mateos <080ariel at gmail dot com> --- Created attachment 55348 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55348&action=edit test2.c
[Bug analyzer/110285] -Wanalyzer-infinite-loop false positive.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110285 --- Comment #3 from Ariel Cabello Mateos <080ariel at gmail dot com> --- Created attachment 55349 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55349&action=edit Preprocessed source of test2.c
[Bug c/110286] New: Wrong code at -O2 on x86_64-linux-gnu (nondeterministic output)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110286
Bug ID: 110286
Summary: Wrong code at -O2 on x86_64-linux-gnu
(nondeterministic output)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: shaohua.li at inf dot ethz.ch
Target Milestone: ---
For the following code, gcc trunk at -O2 emits wrong code. If you run the
compiled code multiple times, you will observe different outputs.
$ cat a.c
int printf(const char *, ...);
char a;
int b;
short c;
short(d)(short e) { return e + c; }
int f;
char g;
char g_0;
int h;
void i() {
for (; h; f++)
switch (g_0)
case '"':
case '\\':
++g;
}
short j;
static int aa;
int k;
const int *l;
const int **m = &l;
short n;
signed o;
int p = 84134051;
unsigned r = 1;
int ag;
static char ah() {
int ai = 0;
if (r)
aj : {
i();
short *ak = &n;
ag = 78003764;
*m = &ag;
*ak = 1;
for (; *l + p - 162153904 + k; k++)
for (; p - 168260671 > 3; ai++) {
*ak = o && 5;
if (a) {
int *al = &aa;
short *am = &j;
*al &= b;
*am = 0;
}
}
if (d((*ak)--))
;
else if (*l)
goto aj;
}
return 0;
}
int main() {
ah();
printf("%d\n", n);
}
$
$ gcc-tk -O0 a.c && ./a.out
0
$ gcc-tk -O2 a.c
$ ./a.out
518
$ ./a.out
514
$
$ gcc-tk -v
Using built-in specs.
COLLECT_GCC=gcc-tk
COLLECT_LTO_WRAPPER=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-27612ce352921d74086102d9ad4d3e011923f837/libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++
--prefix=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-27612ce352921d74086102d9ad4d3e011923f837
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230616 (experimental) (GCC)
$
[Bug middle-end/109849] suboptimal code for vector walking loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
--- Comment #14 from Jan Hubicka ---
One interesting situation is:
void std::vector >::push_back (struct
vector * const this, const struct value_type & __x)
{
struct __normal_iterator D.27894;
struct pair * _1;
struct pair * _2;
struct pair * _3;
[local count: 1073741824]:
_1 = this_6(D)->D.26707._M_impl.D.26014._M_finish;
_2 = this_6(D)->D.26707._M_impl.D.26014._M_end_of_storage;
if (_1 != _2)
goto ; [82.57%]
else
goto ; [17.43%]
[local count: 886588625]:
*_1 = MEM[(const struct pair &)__x_7(D)];
_3 = _1 + 8;
this_6(D)->D.26707._M_impl.D.26014._M_finish = _3;
goto ; [100.00%]
[local count: 187153200]:
D.27894._M_current = _1;
std::vector >::_M_realloc_insert&> (this_6(D), D.27894, __x_7(D));
[local count: 1073741824]:
return;
}
here we could do partial inlining and offline the call to _M_realloc_insert but
we fail to cut since _1 is already load:
Split point at BB 4
header time: 9.302800 header size: 9
split time: 2.440200 split size: 5
bbs: 4
SSA names to pass: 1, 9, 11
Refused: need to pass non-param values
It should be easy to insert code loading the parameter again in the split part.
We still hit the SRA limitation since this would be still escaping, but it is
another missed optimization on this simple testcase.
[Bug libstdc++/110287] New: _M_check_len is expensive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110287
Bug ID: 110287
Summary: _M_check_len is expensive
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
I am looking into ineffective codegen for loops controlled by std::vec based
stack (see testcase in PR109849).
The problem is that we fail to inline enough of implementation of
std::push_back to fully SRA the stack which makes it very slow. The reason is
that _M_realloc_insert currently does not fit in inlining limits for -O2. It
seems to be inlined by clang.
The first issue is rather large _M_check_len that currently does:
size_type std::vector >::_M_check_len
(const struct vector * const this, size_type __n, const char * __s)
{
const size_type __len;
const long unsigned int D.27747;
long unsigned int _1;
long unsigned int __n.3_2;
long unsigned int _3;
size_type iftmp.4_4;
long unsigned int _5;
long unsigned int _8;
long int _10;
long int _13;
struct pair * _14;
struct pair * _15;
const long unsigned int & _18;
[local count: 1073741824]:
_15 = this_7(D)->D.26707._M_impl.D.26014._M_finish;
_14 = this_7(D)->D.26707._M_impl.D.26014._M_start;
_13 = _15 - _14;
_10 = _13 /[ex] 8;
_8 = (long unsigned int) _10;
_1 = 1152921504606846975 - _8;
__n.3_2 = __n;
if (_1 < __n.3_2)
goto ; [0.04%]
else
goto ; [99.96%]
[local count: 429496]:
std::__throw_length_error (__s_16(D));
[local count: 1073312329]:
D.27747 = _8;
if (__n.3_2 > _8)
goto ; [34.00%]
else
goto ; [66.00%]
[local count: 364926196]:
[local count: 1073312330]:
# _18 = PHI <&D.27747(4), &__n(5)>
_3 = *_18;
__len_11 = _3 + _8;
D.27747 ={v} {CLOBBER(eol)};
if (_8 > __len_11)
goto ; [35.00%]
else
goto ; [65.00%]
[local count: 697653013]:
_5 = MIN_EXPR <__len_11, 1152921504606846975>;
[local count: 1073312330]:
# iftmp.4_4 = PHI <1152921504606846975(6), _5(7)>
return iftmp.4_4;
}
Whis is used by _M_realloc_insert:
_20 = std::vector >::_M_check_len
(this_18(D), 1, "vector::_M_realloc_insert");
So _n is 1. The test:
_1 = 1152921504606846975 - _8;
__n.3_2 = __n;
if (_1 < __n.3_2)
goto ; [0.04%]
else
goto ; [99.96%]
[local count: 429496]:
std::__throw_length_error (__s_16(D));
Can IMO be never true, since we would need to have already allocated vector of
1152921504606846975 elements which will not fit in memory anyway.
This brings in the EH handling and error message.
Perhaps for constantly sized _M_check_len and constantly sizes vector elements
we can use __builtin_constant_p to avoid calling _M_check_len from
_M_realloc_insert and invent _M_safe_check_len that avoids this test.
(for IPA optimizations to work out that there will be no EH and call is cheaper
we need to have the test at caller side instead in _M_check_len).
[Bug fortran/110288] New: [11/12/13] Regression: segfault in findloc with allocatable array of allocatable characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110288 Bug ID: 110288 Summary: [11/12/13] Regression: segfault in findloc with allocatable array of allocatable characters Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: zed.three at gmail dot com Target Milestone: --- Created attachment 55350 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55350&action=edit Minimal example source code The following program crashes with a segfault "invalid memory reference" inside `findloc`: program test character(len=:), allocatable, dimension(:) :: array array = ["bb", "bb"] print*, findloc(array, "aa", dim=1) end program Compiler Explorer example: https://godbolt.org/z/Evrnose5o The same program works in gfortran 10.4, crashes in 11+, including trunk (GNU Fortran (Compiler-Explorer-Build-gcc-7ff793415f55fa9a92f348fecb8c75ac8acc8b87-binutils-2.40) 14.0.0 20230616 (experimental)). A minimum of two elements in the array are required, and it must be allocatable, but it doesn't matter if the element is in `array` or not.
[Bug libstdc++/110287] _M_check_len is expensive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110287 --- Comment #1 from Jan Hubicka --- Another problem is: D.27747 = _8; if (__n.3_2 > _8) goto ; [34.00%] else goto ; [66.00%] [local count: 364926196]: [local count: 1073312330]: # _18 = PHI <&D.27747(4), &__n(5)> _3 = *_18; which is simply computation of maximum but done in a way not understood until phiprop
[Bug tree-optimization/110289] New: Phiprop may be good idea in early opts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110289
Bug ID: 110289
Summary: Phiprop may be good idea in early opts
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: hubicka at gcc dot gnu.org
Target Milestone: ---
libstdc++ in push_back operation does equivalent of the following:
int max(int a, int b)
{
int *ptr;
if (a > b)
ptr = &a;
else
ptr = &b;
return *ptr;
}
this is a sily implementation of max operation that sadly is not optimized
until late phiprop pass and confuses inlining heuristics: memory load is
considered to be expensive.
I think this is win-win pass and not very expensive, so perhaps adding it to
early opts is possible?
[Bug target/105617] [12/13/14 Regression] Slp is maybe too aggressive in some/many cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105617 --- Comment #21 from Michael_S --- (In reply to Mason from comment #20) > Doh! You're right. > I come from a background where overlapping/aliasing inputs are heresy, > thus got blindsided :( > > This would be the optimal code, right? > > add4i: > # rdi = dst, rsi = a, rdx = b > movq 0(%rdx), %r8 > movq 8(%rdx), %rax > movq16(%rdx), %rcx > movq24(%rdx), %rdx > addq 0(%rsi), %r8 > adcq 8(%rsi), %rax > adcq16(%rsi), %rcx > adcq24(%rsi), %rdx > movq%r8, 0(%rdi) > movq%rax, 8(%rdi) > movq%rcx, 16(%rdi) > movq%rdx, 24(%rdi) > ret > If one does not care deeply about latency (which is likely for function that stores result into memory) then that looks good enough. But if one does care deeply then I'd expect interleaved loads, as in first 8 lines of code generated by trunk, to produce slightly lower latency on majority of modern CPUs.
[Bug tree-optimization/110289] Phiprop may be good idea in early opts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110289
--- Comment #1 from Jan Hubicka ---
This is caused by the way libstdc++ defines max:
constexpr
inline const _Tp&
max(const _Tp& __a, const _Tp& __b)
{
if (__a < __b)
return __b;
return __a;
}
[Bug rtl-optimization/110215] RA fails to allocate register when loop invariant lives across calls and eh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110215 --- Comment #5 from CVS Commits --- The master branch has been updated by Vladimir Makarov : https://gcc.gnu.org/g:154c69039571c66b3a6d16ecfa9e6ff22942f59f commit r14-1891-g154c69039571c66b3a6d16ecfa9e6ff22942f59f Author: Vladimir N. Makarov Date: Fri Jun 16 11:12:32 2023 -0400 RA: Ignore conflicts for some pseudos from insns throwing a final exception IRA adds conflicts to the pseudos from insns can throw exceptions internally even if the exception code is final for the function and the pseudo value is not used in the exception code. This results in spilling a pseudo in a loop (see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110215). The following patch fixes the problem. PR rtl-optimization/110215 gcc/ChangeLog: * ira-lives.cc: Include except.h. (process_bb_node_lives): Ignore conflicts from cleanup exceptions when the pseudo does not live at the exception landing pad.
[Bug middle-end/31985] Wide operations (i.e. adddi3) are split too late
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31985 --- Comment #4 from CVS Commits --- The master branch has been updated by Roger Sayle : https://gcc.gnu.org/g:95020d33ad6991fe4fbdccf70e7133116cac68f4 commit r14-1892-g95020d33ad6991fe4fbdccf70e7133116cac68f4 Author: Roger Sayle Date: Fri Jun 16 16:18:27 2023 +0100 PR target/31985: Improve memory operand use with doubleword add. This patch addresses the last remaining issue with PR target/31985, that GCC could make better use of memory addressing modes when implementing double word addition. This is achieved by adding a define_insn_and_split that combines an *add3_doubleword with a *concat3, so that the components of the concat can be used directly, without first being loaded into a double word register. For test_c in the bugzilla PR: Before: pushl %ebx subl$16, %esp movl28(%esp), %eax movl36(%esp), %ecx movl32(%esp), %ebx movl24(%esp), %edx addl%ecx, %eax adcl%ebx, %edx movl%eax, 8(%esp) movl%edx, 12(%esp) addl$16, %esp popl%ebx ret After: test_c: subl$20, %esp movl36(%esp), %eax movl32(%esp), %edx addl28(%esp), %eax adcl24(%esp), %edx movl%eax, 8(%esp) movl%edx, 12(%esp) addl$20, %esp ret 2023-06-16 Roger Sayle Uros Bizjak gcc/ChangeLog PR target/31985 * config/i386/i386.md (*add3_doubleword_concat): New define_insn_and_split combine *add3_doubleword with a *concat3 for more efficient lowering after reload. gcc/testsuite/ChangeLog PR target/31985 * gcc.target/i386/pr31985.c: New test case.
[Bug tree-optimization/110289] Phiprop may be good idea in early opts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110289
--- Comment #2 from Jan Hubicka ---
This patch fixes the problem
diff --git a/gcc/passes.def b/gcc/passes.def
index c9a8f19747b..faa5208b26b 100644
--- a/gcc/passes.def
+++ b/gcc/passes.def
@@ -88,6 +88,8 @@ along with GCC; see the file COPYING3. If not see
/* pass_build_ealias is a dummy pass that ensures that we
execute TODO_rebuild_alias at this point. */
NEXT_PASS (pass_build_ealias);
+ /* Do phiprop before FRE so we optimize std::min and std::max well.
*/
+ NEXT_PASS (pass_phiprop);
NEXT_PASS (pass_fre, true /* may_iterate */);
NEXT_PASS (pass_early_vrp);
NEXT_PASS (pass_merge_phi);
diff --git a/gcc/tree-ssa-phiprop.cc b/gcc/tree-ssa-phiprop.cc
index 3cb4900b6be..5dc505df420 100644
--- a/gcc/tree-ssa-phiprop.cc
+++ b/gcc/tree-ssa-phiprop.cc
@@ -476,6 +476,7 @@ public:
{}
/* opt_pass methods: */
+ opt_pass * clone () final override { return new pass_phiprop (m_ctxt); }
bool gate (function *) final override { return flag_tree_phiprop; }
unsigned int execute (function *) final override;
and helps PR110287
[Bug libstdc++/110287] _M_check_len is expensive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110287
--- Comment #2 from Jan Hubicka ---
With patch in PR110289 to optimize the std::max int MAX_EXPR and the throw
commented out I get:
size_type std::vector >::_M_check_len
(const struct vector * const this, size_type __n, const char * __s)
{
const size_type __len;
size_type iftmp.2_1;
long unsigned int _2;
long unsigned int _5;
long unsigned int _7;
struct pair * _8;
struct pair * _9;
long int _10;
long int _11;
long unsigned int _12;
[local count: 1073741824]:
_8 = this_4(D)->D.26707._M_impl.D.26014._M_finish;
_9 = this_4(D)->D.26707._M_impl.D.26014._M_start;
_10 = _8 - _9;
_11 = _10 /[ex] 8;
_12 = (long unsigned int) _11;
_7 = __n;
_5 = MAX_EXPR <_7, _12>;
__len_6 = _5 + _12;
if (__len_6 < _12)
goto ; [35.00%]
else
goto ; [65.00%]
[local count: 697932185]:
_2 = MIN_EXPR <__len_6, 1152921504606846975>;
[local count: 1073741824]:
# iftmp.2_1 = PHI <1152921504606846975(2), _2(3)>
return iftmp.2_1;
}
which fits early inlining limits. So modifying libstdc++ to avoid the throw
would be great.
Again optimized _M_check_len could avoid:
[local count: 697932185]:
_2 = MIN_EXPR <__len_6, 1152921504606846975>;
[local count: 1073741824]:
# iftmp.2_1 = PHI <1152921504606846975(2), _2(3)>
return iftmp.2_1;
since __len can not get that large without running out of memory. Which would
help further inlining.
Testcase from PR109849 now runs in 0.39s while without these two changes it
runs in 0.528s, clang's build runs in 0.057s, so still a long way to go.
[Bug target/86793] mips port needs updating for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86793 Richard Earnshaw changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |14.0 --- Comment #3 from Richard Earnshaw --- Fixed on main development branch.
[Bug target/86772] [meta-bug] tracking port status for CVE-2017-5753
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86772 Bug 86772 depends on bug 86793, which changed state. Bug 86793 Summary: mips port needs updating for CVE-2017-5753 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86793 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug ipa/110276] [13/14 Regression] ICE building efibootguard on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110276 --- Comment #3 from Martin Jambor --- I have proposed a fix on the mailing list: https://gcc.gnu.org/pipermail/gcc-patches/2023-June/622019.html
[Bug fortran/110288] [11/12/13/14] Regression: segfault in findloc with allocatable array of allocatable characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110288 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Summary|[11/12/13] Regression: |[11/12/13/14] Regression: |segfault in findloc with|segfault in findloc with |allocatable array of|allocatable array of |allocatable characters |allocatable characters Target Milestone|--- |11.5 Last reconfirmed||2023-06-16 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed.
[Bug target/110273] [12/13/14 Regression] i686-w64-mingw32 with -mavx512f generates AVX instructions without stack alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110273 --- Comment #5 from H.J. Lu --- GCC doesn't align stack for Windows. As a workaround, one can pass -muse-unaligned-vector-move to newer assembler.
[Bug fortran/107900] Select type with intrinsic type inside associate causes ICE / Segmenation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107900
Paul Thomas changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org
--- Comment #2 from Paul Thomas ---
Created attachment 55351
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55351&action=edit
Fix for this PR
Testcase:
! { dg-do run }
!
! Contributed by Karl Kaiser
!
program test
class(*), pointer :: ptr1, ptr2(:)
integer, target :: i = 42
integer :: check = 0
! ptr1 => NULL()!This would fix the problem
associate (c => ptr1)
block
select type (d => c)
type is (integer)
stop 1
class default
check = 1
end select
end block
end associate
! Now do the same with the array version
! ptr2 => NULL()!This did not fix the problem
associate (c => ptr2)
block
select type (d => c)
type is (integer)
stop 2
class default
check = check + 10
end select
end block
end associate
if (check .ne. 11) stop 3
end program test
Regards
Paul
[Bug target/110273] [12/13/14 Regression] i686-w64-mingw32 with -mavx512f generates AVX instructions without stack alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110273 --- Comment #6 from Alexander Monakov --- Huh? Just compile the supplied testcases without avx512, you'll see proper stack realignment.
[Bug tree-optimization/110271] [14 Regression] UICE on pycryptodome-3.17.0 during GIMPLE pass: widening_mul: in gsi_replace, at gimple-iterator.cc:437
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110271 --- Comment #5 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:5b67116a85298bbe358b036d34ad23119cebbdac commit r14-1895-g5b67116a85298bbe358b036d34ad23119cebbdac Author: Jakub Jelinek Date: Fri Jun 16 19:46:36 2023 +0200 tree-ssa-math-opts: Fix up uaddc/usubc pattern matching [PR110271] The following testcase ICEs, because I misremembered what the return value from match_arith_overflow is. It isn't true if __builtin_*_overflow was matched, but it is true only in the BIT_NOT_EXPR case if stmt was removed. So, if match_arith_overflow matches something, gsi_stmt (gsi) will not be stmt and match_uaddc_usubc will be confused and can ICE. The following patch fixes it by checking if gsi_stmt (gsi) == stmt, in that case we know it is still a PLUS_EXPR/MINUS_EXPR and we can try to pattern match it further as UADDC/USUBC. 2023-06-16 Jakub Jelinek PR tree-optimization/110271 * tree-ssa-math-opts.cc (math_opts_dom_walker::after_dom_children) : Ignore return value from match_arith_overflow, instead call match_uaddc_usubc only if gsi_stmt (gsi) is still stmt. * gcc.c-torture/compile/pr110271.c: New test.
[Bug middle-end/79173] add-with-carry and subtract-with-borrow support (x86_64 and others)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79173
--- Comment #22 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:2b4e0415ad664cdb3ce87d1f7eee5ca26911a05b
commit r14-1896-g2b4e0415ad664cdb3ce87d1f7eee5ca26911a05b
Author: Jakub Jelinek
Date: Fri Jun 16 19:47:28 2023 +0200
uiltins: Add support for clang compatible __builtin_{add,sub}c{,l,ll}
[PR79173]
While the design of these builtins in clang is questionable,
rather than being say
unsigned __builtin_addc (unsigned, unsigned, bool, bool *)
so that it is clear they add two [0, 0x] range numbers
plus one [0, 1] range carry in and give [0, 0x] range
return plus [0, 1] range carry out, they actually instead
add 3 [0, 0x] values together but the carry out
isn't then the expected [0, 2] value because
0xULL + 0x + 0x is 0x2fffd,
but just [0, 1] whether there was any overflow at all.
It is something used in the wild and shorter to write than the
corresponding
#define __builtin_addc(a,b,carry_in,carry_out) \
({ unsigned _s; \
unsigned _c1 = __builtin_uadd_overflow (a, b, &_s); \
unsigned _c2 = __builtin_uadd_overflow (_s, carry_in, &_s); \
*(carry_out) = (_c1 | _c2); \
_s; })
and so a canned builtin for something people could often use.
It isn't that hard to maintain on the GCC side, as we just lower
it to two .ADD_OVERFLOW calls early, and the already committed
pottern recognization code can then make .UADDC/.USUBC calls out of
that if the carry in is in [0, 1] range and the corresponding
optab is supported by the target.
2023-06-16 Jakub Jelinek
PR middle-end/79173
* builtin-types.def (BT_FN_UINT_UINT_UINT_UINT_UINTPTR,
BT_FN_ULONG_ULONG_ULONG_ULONG_ULONGPTR,
BT_FN_ULONGLONG_ULONGLONG_ULONGLONG_ULONGLONG_ULONGLONGPTR): New
types.
* builtins.def (BUILT_IN_ADDC, BUILT_IN_ADDCL, BUILT_IN_ADDCLL,
BUILT_IN_SUBC, BUILT_IN_SUBCL, BUILT_IN_SUBCLL): New builtins.
* builtins.cc (fold_builtin_addc_subc): New function.
(fold_builtin_varargs): Handle BUILT_IN_{ADD,SUB}C{,L,LL}.
* doc/extend.texi (__builtin_addc, __builtin_subc): Document.
* gcc.target/i386/pr79173-11.c: New test.
* gcc.dg/builtin-addc-1.c: New test.
[Bug tree-optimization/110289] Phiprop may be good idea in early opts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110289 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Keywords||missed-optimization Last reconfirmed||2023-06-16 Status|UNCONFIRMED |NEW Severity|normal |enhancement --- Comment #3 from Andrew Pinski --- Yes this should definitely run after early inline in the early optimizations because of C++ code.
[Bug tree-optimization/110271] [14 Regression] UICE on pycryptodome-3.17.0 during GIMPLE pass: widening_mul: in gsi_replace, at gimple-iterator.cc:437
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110271 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from Jakub Jelinek --- Should be fixed now.
[Bug fortran/110290] New: Assumed-length character dummy with VALUE attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110290 Bug ID: 110290 Summary: Assumed-length character dummy with VALUE attribute Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: anlauf at gcc dot gnu.org Target Milestone: --- The following valid code is rejected: subroutine s (x) character(*), value :: x ! rejected end 1 | subroutine s (x) | 1 Error: Character dummy variable 'x' at (1) with VALUE attribute must have constant length Note that fixed length works: subroutine s2 (x) character(4), value :: x ! OK end It appears that there never was such a restriction in the standard.
[Bug fortran/92178] Segmentation fault after passing allocatable array as intent(out) and its element as value into the same subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178 --- Comment #14 from anlauf at gcc dot gnu.org --- I looked at cases with character arguments, and it appears that there is a general issue with (lack or improper) generation of temporaries. Consider: program p implicit none character(4), allocatable :: a(:) integer :: k = -999 a = ["aa","bb"] ! call assign_s (a, (a(2) // "")) ! OK ! call assign_s (a, a(2) // "" ) ! OK ! call assign_s (a, (a(2))) ! no proper temporary ! call assign_s (a, a(2) ) ! invalid Fortran call assign_s (a, (a(2)(1:3))) ! no proper temporary print *, allocated (a), k contains subroutine assign_s (a, b) character(*), allocatable, intent(out) :: a(:) ! character(*), value :: b! rejected (-> pr110290) character(*) :: b k = len (b) print *, b end subroutine end The first two variants work as expected, the fourth is IMHO invalid because of aliasing, but the third and fifth should work. However, compiling with -fsanitize=address,undefined shows that they don't. Inspecting the dump-tree suggests that there is no proper temporary for the second argument, even though it is requested. Also, running under gdb, I see that the gfc_evaluate_now from the patch is called. Do we need to do something special to get temporaries here?
[Bug fortran/110290] Assumed-length character dummy with VALUE attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110290 --- Comment #1 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #0) > It appears that there never was such a restriction in the standard. There actually was a restriction in F2003, mentioned by Tobias in pr49802#c1: C528 (R501) If the VALUE attribute is specified, the length type parameter values shall be omitted or specified by initialization expressions. There is also a proof-of-principle patch attached, might be worth to look into again.
[Bug fortran/92887] [F2008] Passing nullified/disassociated pointer or unalloc allocatable to OPTIONAL + VALUE dummy fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92887 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||anlauf at gcc dot gnu.org Last reconfirmed||2023-06-16 --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed.
[Bug target/109541] [12/13 regression] ICE in extract_constrain_insn on when building rhash-1.4.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109541 --- Comment #20 from CVS Commits --- The releases/gcc-13 branch has been updated by Vladimir Makarov : https://gcc.gnu.org/g:5568d224f2e179b8e91a90fa4fba10bd8a7f963d commit r13-7451-g5568d224f2e179b8e91a90fa4fba10bd8a7f963d Author: Vladimir N. Makarov Date: Wed Jun 7 09:51:54 2023 -0400 RA: Constrain class of pic offset table pseudo to general regs On some targets an integer pseudo can be assigned to a FP reg. For pic offset table pseudo it means we will reload the pseudo in this case and, as a consequence, memory containing the pseudo might be recognized as wrong one. The patch fix this problem. PR target/109541 gcc/ChangeLog: * ira-costs.cc: (find_costs_and_classes): Constrain classes of pic offset table pseudo to a general reg subset. gcc/testsuite/ChangeLog: * gcc.target/sparc/pr109541.c: New.
[Bug c++/110291] New: [11.1 Regression] constraint on friend operator template causes bizarre duplication of RHS template parameter that is passed to the requires expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110291
Bug ID: 110291
Summary: [11.1 Regression] constraint on friend operator
template causes bizarre duplication of RHS template
parameter that is passed to the requires expression
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: waffl3x at protonmail dot com
Target Milestone: ---
template
struct fn { using type = decltype(L{} + R{}); };
struct no_self {};
no_self operator+(int, no_self);
void operator+(no_self, no_self) = delete;
template
struct expr {
template
requires requires {typename fn::type;}
friend void operator/(expr, expr);
};
using X = decltype(expr{} / expr{});
https://godbolt.org/z/on1KdfY9T
`error: use of deleted function 'void operator+(no_self, no_self)'`
Working in GCC 9.5 and GCC 10.4, broken in 11.1 and onward. Not too much of a
monologue from me this time, I couldn't beat much interesting information out
of it. Best I can tell is it's definitely related to the constraint (note that
separating it into a concept does not fix the issue), and it being a friend
operator is relevant. I am pretty sure the addition operator overload is not
related, it's just related to what I was doing when I encountered the bug. I'm
pretty sure there is another layer that could be peeled off here, but it
started to hurt my head and for a small bug I think this should be good enough.
It almost seems like it's caching U and preemptively evaluating the RHS as a
LHS with the cached U type. I wanted to confirm this somehow, but like I said,
it just wasn't cooperating. My experimenting was just resulting in much much
more complicated examples,so I decided to just call it here.
[Bug c++/110291] [11.1 Regression] constraint on friend operator template causes bizarre duplication of RHS template parameter that is passed to the requires expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110291 --- Comment #1 from waffl3x --- I opened Bug 110006 and forgot to check before submitting, looking over at it, I'm pretty sure it's the same bug, and if not, then probably related. https://godbolt.org/z/7zoWfG4Ws I checked their reproduction and sure enough, it's also an 11.1 regression just like this one, so it is almost certainly the same. So this should probably be marked as a duplicate of it? I'm not really sure what the protocol for that is though so I'll leave it to someone else.
[Bug tree-optimization/110271] [14 Regression] UICE on pycryptodome-3.17.0 during GIMPLE pass: widening_mul: in gsi_replace, at gimple-iterator.cc:437
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110271 --- Comment #7 from Sergei Trofimovich --- I confirm the fix also fixes pycryptodome-3.17.0 package build. Thank you!
[Bug c++/110006] friend function template with constraint doesn't match existing declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110006 waffl3x changed: What|Removed |Added CC||waffl3x at protonmail dot com --- Comment #1 from waffl3x --- I am pretty certain Bug 110291 is a duplicate of this one
[Bug c/110292] New: undefined value due to strict aliasing without warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110292
Bug ID: 110292
Summary: undefined value due to strict aliasing without warning
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: yann at droneaud dot fr
Target Milestone: ---
The following code (reduced with some help from cvise) doesn't trigger any
warning from GCC 13+
$ cat test.c
#include
struct a {
uint8_t b:6;
};
struct c {
uint64_t d:6;
};
void e(uint64_t *f, uint64_t *g) {
struct c *h = (struct c *)f;
struct a i[8] = { [7] = { h -> d } };
__builtin___memcpy_chk (g, i, sizeof(i),
__builtin_object_size (g, 0));
}
int main(void) {
uint64_t j = 0;
uint64_t k;
e(&j, &k);
if (k)
__builtin_trap();
return 0;
}
But compiled under Fedora 39 (Rawhide, gcc 13.1.1-2, x86_64), it aborts,
because j location on the stack is not set to 0 before its address is being
passed to e() ...
$ gcc -Wall -Wextra -O2 test.c -o test
$ ./test
Aborted (core dumped)
Even if it doesn't abort (because the stack is cleared), there's a problem and
valgrind reports:
$ gcc -Wall -Wextra -O2 -g3 test.c -o test
$ valgrind --track-origins=yes ./test
==63110== Memcheck, a memory error detector
==63110== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==63110== Using Valgrind-3.21.0 and LibVEX; rerun with -h for copyright
info
==63110== Command: ./test
==63110==
==63110== Conditional jump or move depends on uninitialised value(s)
==63110==at 0x401047: main (test.c:22)
==63110== Uninitialised value was created by a stack allocation
==63110==at 0x401030: main (test.c:18)
...
And, as one could see, line 18 doesn't match any of the variables that are
allocated.
Below, the assembly compiled by GCC:
$ gcc -Wall -Wextra -O2 -g3 test.c -S
$ cat test.s
e:
movzbl (%rdi), %eax
andl$63, %eax
salq$56, %rax
movq%rax, (%rsi)
ret
main:
subq$16, %rsp
leaq8(%rsp), %rsi
movq%rsp, %rdi
calle
cmpq$0, 8(%rsp)
jne .L5
xorl%eax, %eax
addq$16, %rsp
ret
.L5:
ud2
Code available at https://godbolt.org/z/b8sn314K9
Is it an aliasing issue in the code and GCC doesn't reports a warning ? Or
worse ?
[Bug c/110292] undefined value due to strict aliasing without warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110292 Yann Droneaud changed: What|Removed |Added CC||yann at droneaud dot fr --- Comment #1 from Yann Droneaud --- And it should be noted that using -fsanitize=undefined is making the issue vanish as 0 is written into j location on the stack ...
[Bug tree-optimization/110283] Bogus Warray-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110283
--- Comment #2 from Andrew Pinski ---
As an aside, Eigen has some maybe wrong code in it:
```
# 55 "../../eigen-3.3.4/Eigen/src/Core/arch/SSE/PacketMath.h" 3 4
typedef __m128 Packet4f;
typedef __m128i Packet4i;
typedef __m128d Packet2d;
template<> struct is_arithmetic<__m128> { enum { value = true }; };
template<> struct is_arithmetic<__m128i> { enum { value = true }; };
template<> struct is_arithmetic<__m128d> { enum { value = true }; };
...
template<> struct unpacket_traits { typedef float type; enum {size=4,
alignment=Aligned16}; typedef Packet4f half; };
template<> struct unpacket_traits { typedef double type; enum
{size=2, alignment=Aligned16}; typedef Packet2d half; };
template<> struct unpacket_traits { typedef int type; enum {size=4,
alignment=Aligned16}; typedef Packet4i half; };
```
Because __m128/__m128i/__m128d are all declared as may_alias but the template
will lose that attribute.
[Bug c/110292] undefined value due to strict aliasing without warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110292 --- Comment #2 from Andrew Pinski --- aliasing violations are known not to be warned about nor have a runtime sanitizer either.
[Bug middle-end/110292] undefined value due to strict aliasing without warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110292
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |WONTFIX
--- Comment #3 from Andrew Pinski ---
So this is IPA modref in action.
loads:
Base 0: alias set 1
Ref 0: alias set 1
access: Parm 0 param offset:0 offset:0 size:6 max_size:6
stores:
Base 0: alias set 0
Ref 0: alias set 0
access: Parm 1 param offset:0 offset:0 size:-1 max_size:64
So we know that e only does a store to the second argument (via aliasing set 0
which is the is the root of all aliasing sets) and loads from the first
argument with an aliasing set of 1( in this case it is the aliasing set that is
contained for struct c).
So when DSE comes a long, it removes the store to j as it not used by the e
function as it is in the non-conflicting aliasing set of e.
Note casting does not change aliasing sets even.
In that main could have been:
```
int main(void) {
struct c t = {0};
uint64_t k;
e((uint64_t*)&t, &k);
if (k)
__builtin_trap();
return 0;
}
```
And that would have been valid and well defined code.
[Bug middle-end/110292] undefined value due to strict aliasing without warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110292 Andrew Pinski changed: What|Removed |Added Resolution|WONTFIX |INVALID --- Comment #4 from Andrew Pinski --- Note -Wstrict-aliasing=1 actually does warn: : In function 'e': :13:29: warning: dereferencing type-punned pointer might break strict-aliasing rules [-Wstrict-aliasing] 13 | struct c *h = (struct c *)f; | ^
[Bug analyzer/110285] -Wanalyzer-infinite-recursion false positive involving floating-point values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110285 David Malcolm changed: What|Removed |Added Summary|-Wanalyzer-infinite-recursi |-Wanalyzer-infinite-recursi |on false positive |on false positive involving ||floating-point values --- Comment #4 from David Malcolm --- Thanks for filing this. -fanalyzer currently doesn't attempt to track conditions involving floating point, so it incorrectly treats both A and !A as potentially being true along an execution path, leading to the false positive. Sorry about this.
[Bug tree-optimization/110280] internal compiler error: in const_unop, at fold-const.cc:1884
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110280 --- Comment #3 from Andrew Pinski --- #6 0x0087710b in const_unop (code=VEC_UNPACK_LO_EXPR, type=, arg0=) at ../../gcc/fold-const.cc:1954 1954gcc_assert (known_eq (out_nelts, TYPE_VECTOR_SUBPARTS (type)));
[Bug tree-optimization/110280] internal compiler error: in const_unop, at fold-const.cc:1884
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110280 --- Comment #4 from Andrew Pinski --- (gdb) p debug_gimple_stmt(stmt) _41 = [vec_unpack_lo_expr] _40;
[Bug target/54089] [SH] Refactor shift patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089 --- Comment #76 from Oleg Endo --- (In reply to Alexander Klepikov from comment #75) > I found that patch incorrectly works when '-O0 -fmove-loop-invariants' flags > are set. Stock loop optimization passes do not run when '-O0' is specified > desipte '-fmove-loop-invariants' is set. I'll do the same and recheck again. It'd be good if the newly added passes are ran only with -O2 or higher. Or even better, if we can find a way to enable them only when actually needed. E.g. when it's splitting a shift insn that will potentially need the loop optimizations again, set a flag in the function. One way to do that could be adding SH specific function context class/struct to store some per-function data for the compilation process. Right now we'd have only one entry, that is whether to run the additional passes again or not. This per-function 'SH context' can be stored as a global variable in sh.cc. Then override 'set_current_function' in the backend to reset the SH specific per-function context. However, to get better test coverage, it's better first let the additional loop passes run all the time to uncover any potential issues. Later the above can be added as a supplementary optimization.
[Bug c/110286] Wrong code at -O2 on x86_64-linux-gnu (nondeterministic output)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110286 --- Comment #1 from Andrew Pinski --- phiopt match-simplify trying: n_lsm_flag.36_58 != 0 ? n_lsm.35_15 : 1 Matching expression match.pd:1990, gimple-match-5.cc:23 Matching expression match.pd:1990, gimple-match-5.cc:23 Matching expression match.pd:1990, gimple-match-5.cc:23 Matching expression match.pd:1947, gimple-match-7.cc:20 Matching expression match.pd:2479, gimple-match-4.cc:35 Matching expression match.pd:2482, gimple-match-3.cc:66 Matching expression match.pd:2489, gimple-match-2.cc:58 Applying pattern match.pd:6445, gimple-match-4.cc:12746 Applying pattern match.pd:1378, gimple-match-2.cc:7699 Applying pattern match.pd:1885, gimple-match-3.cc:2770 Applying pattern match.pd:4745, gimple-match-7.cc:15371 Folded into the sequence: _112 = (short int) n_lsm_flag.36_58; _85 = ~n_lsm_flag.36_58; _34 = (short int) _85; _87 = n_lsm.35_15 | _34;
[Bug c/110286] Wrong code at -O2 on x86_64-linux-gnu (nondeterministic output)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110286 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- Dup of bug 110228. *** This bug has been marked as a duplicate of bug 110228 ***
[Bug middle-end/110228] [14 Regression] llvm-16 miscompiled due to an maybe uninitialized and optimizations saying that the uninitialized has a nonzero bits of 1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228 Andrew Pinski changed: What|Removed |Added CC||shaohua.li at inf dot ethz.ch --- Comment #10 from Andrew Pinski --- *** Bug 110286 has been marked as a duplicate of this bug. ***
[Bug c/110286] Wrong code at -O2 on x86_64-linux-gnu (nondeterministic output)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110286 --- Comment #3 from Andrew Pinski --- In this case we have: # RANGE [irange] short int [0, 1] NONZERO 0x1 # n_lsm.35_15 = PHI <_10(9), n_lsm.35_45(12)> ... # RANGE [irange] short int [0, 1] NONZERO 0x1 # n_lsm.35_45 = PHI # RANGE [irange] short int [0, 1] NONZERO 0x1 _10 = (short intD.17) _9; But the range of _69(D) is really undefined There is nothing phiopt/match is doing incorrectly due to the above, rather it is ranger that might be considering the wrong/incorrect information for uninitialized variables ...
[Bug middle-end/110228] [14 Regression] llvm-16 miscompiled due to an maybe uninitialized and optimizations saying that the uninitialized has a nonzero bits of 1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110228 --- Comment #11 from Andrew Pinski --- >From the duplicate bug report analysis: # RANGE [irange] short int [0, 1] NONZERO 0x1 # n_lsm.35_15 = PHI <_10(9), n_lsm.35_45(12)> ... # RANGE [irange] short int [0, 1] NONZERO 0x1 # n_lsm.35_45 = PHI # RANGE [irange] short int [0, 1] NONZERO 0x1 _10 = (short intD.17) _9; But the range of _69(D) is really undefined There is nothing phiopt/match is doing incorrectly due to the above, rather it is ranger that might be considering the wrong/incorrect information for uninitialized variables ...
[Bug tree-optimization/110293] New: Some `A CMP (A NEEQ 0)` is not simplified in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110293 Bug ID: 110293 Summary: Some `A CMP (A NEEQ 0)` is not simplified in some cases Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: enhancement Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- The full set is: `x != (typeof x)(x == 0)` is always true (PR 110278) `x == (typeof x)(x == 0)` is always false. `x == (typeof x)(x != 0)` is `(unsigned_type)x <= 1` `x != (typeof x)(x != 0)` is `(unsigned_type)x > 1` `uns < (typeof uns)(uns != 0)` is always false (PR 110278) `uns >= (typeof uns)(uns != 0)` is always true `uns <= (typeof uns)(uns != 0)` is `uns <= 1` `uns > (typeof uns)(uns != 0)` is `uns > 1`
[Bug target/110264] internal compiler error: riscv_vector::vector_insn_info::get_avl_reg_rtx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110264 --- Comment #4 from CVS Commits --- The master branch has been updated by Pan Li : https://gcc.gnu.org/g:dd6e1cbac8682106c5167c105f2807014288b852 commit r14-1898-gdd6e1cbac8682106c5167c105f2807014288b852 Author: Juzhe-Zhong Date: Fri Jun 16 16:02:31 2023 +0800 RISC-V: Fix VL operand bug in VSETVL PASS[PR110264] This patch fixes this issue happens on both GCC-13 and GCC-14. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110264 The testcase is too big and I failed to reduce it so I didn't append test into this patch. This patch should not only land into GCC-14 but also should backport to GCC-13. PR target/110264 gcc/ChangeLog: * config/riscv/riscv-vsetvl.cc (insert_vsetvl): Fix bug.
[Bug tree-optimization/110266] [14 Regression] ice in gimple_range_adjustment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110266 Andrew Pinski changed: What|Removed |Added CC||zsojka at seznam dot cz --- Comment #10 from Andrew Pinski --- *** Bug 110219 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/110219] [14 Regression] ICE: tree check: expected integer_cst, have real_cst in to_wide, at tree.h:6314 with _Complex float to int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110219 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #3 from Andrew Pinski --- Dup of bug 110266. *** This bug has been marked as a duplicate of bug 110266 ***
