[Bug c/115290] New: tree check fail in c_tree_printer, at c/c-objc-common.cc:330
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115290 Bug ID: 115290 Summary: tree check fail in c_tree_printer, at c/c-objc-common.cc:330 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- For this C code: $ more bug1029.c typedef enum { SERVER_HELLO_DONE } message_type_t; message_type_t handshakes[256][32], tls13_handshakes[256][32]; void main() { (0 ? tls13_handshakes : handshakes) == tls13_handshakes; } $ compiled as follows: $ ~/gcc/results/bin/gcc -c -Wall bug1029.c does this: bug1029.c:3:6: warning: return type of ‘main’ is not ‘int’ [-Wmain] 3 | void main() { (0 ? tls13_handshakes : handshakes) == tls13_handshakes; } | ^~~~ bug1029.c: In function ‘main’: bug1029.c:3:51: warning: comparison between two arrays [-Warray-compare] 3 | void main() { (0 ? tls13_handshakes : handshakes) == tls13_handshakes; } | ^~ tree check: expected tree that contains ‘decl minimal’ structure, have ‘cond_exp r’ in c_tree_printer, at c/c-objc-common.cc:330 3 | void main() { (0 ? tls13_handshakes : handshakes) == tls13_handshakes; } | ^~~~ 0x81bb1e tree_contains_struct_check_failed(tree_node const*, tree_node_structure _enum, char const*, int, char const*) ../../trunk.20210101/gcc/tree.cc:9169 0x6e18a8 contains_struct_check(tree_node*, tree_node_structure_enum, char const* , int, char const*) ../../trunk.20210101/gcc/tree.h:3770 0x6e18a8 c_tree_printer ../../trunk.20210101/gcc/c/c-objc-common.cc:330 The bug first appeared sometime before git hash 28b508233a12c132.
[Bug plugins/115288] New: File label-text.h not part of installation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115288 Bug ID: 115288 Summary: File label-text.h not part of installation Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: plugins Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- I have just tried a linux kernel build with this morning's gcc trunk compiler and I got this: home/dcb40b/gcc/results.20240530.asan.ubsan/lib/gcc/x86_64-pc-linux-gnu/15.0.0/plugin/include/rich-location.h:25:10: fatal error: label-text.h: No such file or directory 25 | #include "label-text.h" | ^~ Doing this $ cp /home/dcb40b/gcc/trunk.20210101/libcpp/include/label-text.h /home/dcb40b/gcc/results.20240530.asan.ubsan/bin/../lib/gcc/x86_64-pc-linux-gnu/15.0.0/plugin/include/ $ seems to solve the problem. It looks to me like someone forgot to add file label-text.h to some list in the install make target.
[Bug tree-optimization/115243] error: stmt with wrong VUSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115243 --- Comment #3 from David Binderman --- Looks fixed to me.
[Bug c/115243] New: error: stmt with wrong VUSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115243 Bug ID: 115243 Summary: error: stmt with wrong VUSE Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- This reduced C code: int g_6, func_11; void func_8(); void func_39( int * p_41, long p_42) { char trans_9; func_11 = trans_9 >= 32 ? p_42 : p_42 >> trans_9; if (func_11) *p_41 = 0; int l_59 = g_6; func_39( _59, 10); func_8(_59); } does this with recent gcc: [dcb38@fedora ~]$ ~/gcc/results/bin/gcc -c -w -O1 bug1030.c [dcb38@fedora ~]$ ~/gcc/results/bin/gcc -c -w -O2 bug1030.c bug1030.c: In function ‘func_39’: bug1030.c:4:6: error: stmt with wrong VUSE 4 | void func_39( int * p_41, long p_42) | ^~~ # .MEM_74 = VDEF <.MEM_6> l_59 = 0; expected .MEM_13
[Bug fortran/114871] New: valgrind error in gfc_class_vptr_get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114871 Bug ID: 114871 Summary: valgrind error in gfc_class_vptr_get Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- >From the flang test suite at https://github.com/llvm/llvm-project/tree/main/flang/test, the file ./Lower/Intrinsics/spread.f90, does this: $ ~/gcc/results.20240427.valgrind/bin/gfortran -c -w ./Lower/Intrinsics/spread.f90 ==1511945== Invalid read of size 2 ==1511945==at 0x86B811: gfc_class_vptr_get(tree_node*) (trans-expr.cc:247) ==1511945==by 0x883366: trans_class_vptr_len_assignment(stmtblock_t*, gfc_expr*, gfc_expr*, gfc_se*, tree_node**, tree_node**, tree_node**) (trans-expr.cc:10146) ==1511945==by 0x8863A2: trans_class_assignment (trans-expr.cc:11969) ==1511945==by 0x8863A2: gfc_trans_assignment_1(gfc_expr*, gfc_expr*, bool, bool, bool, bool) (trans-expr.cc:12435)
[Bug fortran/113917] ice in gfc_class_vptr_get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113917 --- Comment #2 from David Binderman --- Bit more detail from valgrind: ==1450005== Invalid read of size 2 ==1450005==at 0x86B811: gfc_class_vptr_get(tree_node*) (trans-expr.cc:247) ==1450005==by 0x883366: trans_class_vptr_len_assignment(stmtblock_t*, gfc_expr*, gfc_expr*, gfc_se*, tree_node**, tree_node**, tree_node**) (trans-expr.cc:10146) ==1450005==by 0x8863A2: trans_class_assignment (trans-expr.cc:11969) ==1450005==by 0x8863A2: gfc_trans_assignment_1(gfc_expr*, gfc_expr*, bool, bool, bool, bool) (trans-expr.cc:12435)
[Bug fortran/93814] [11/12/13/14/15 Regression] ICE in build_entry_thunks, at fortran/trans-decl.c:2898
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93814 --- Comment #12 from David Binderman --- Bit more detail: ./Lower/HLFIR/bindc-entry-stmt.f90:5:0: 5 | function foo() bind(c) Warning: Variable ‘foo’ at (1) may not be a C interoperable kind but it is BIND(C) [-Wc-binding-type] ./Lower/HLFIR/bindc-entry-stmt.f90:39:28: 39 | character(1) :: foo2, bar2 |1 Warning: Variable ‘bar2’ at (1) may not be a C interoperable kind but it is BIND(C) [-Wc-binding-type] ==1442522== Invalid read of size 8 ==1442522==at 0x862E5E: quick_push (vec.h:1043) ==1442522==by 0x862E5E: vec_safe_push (vec.h:835) ==1442522==by 0x862E5E: build_entry_thunks (trans-decl.cc:3002) ==1442522==by 0x862E5E: gfc_create_function_decl(gfc_namespace*, bool) (trans-decl.cc:3157)
[Bug fortran/114739] [14 Regression] ice in gfc_find_derived_types, at fortran/symbol.cc:2458
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114739 --- Comment #2 from David Binderman --- Created attachment 57959 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57959=edit F90 source code
[Bug fortran/114739] New: [14 Regression] ice in gfc_find_derived_types, at fortran/symbol.cc:2458
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114739 Bug ID: 114739 Summary: [14 Regression] ice in gfc_find_derived_types, at fortran/symbol.cc:2458 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- >From the flang testsuite at https://github.com/llvm/llvm-project/tree/main/flang/test file ./Semantics/symbol07.f90, does this with gfortran 13.2: $ ~/gcc/results.13.2.asan.ubsan/bin/gfortran -c -w ./Semantics/symbol07.f90 ./Semantics/symbol07.f90:28:5: 28 | z2%re = x | 1 Error: Symbol ‘z2’ at (1) has no IMPLICIT type ./Semantics/symbol07.f90:31:5: 31 | z2%im = y | 1 Error: Symbol ‘z2’ at (1) has no IMPLICIT type $ and this with yesterday's gfortran: $ ~/gcc/results.20240415.asan.ubsan/bin/gfortran -c -w ./Semantics/symbol07.f90 f951: internal compiler error: in gfc_find_derived_types, at fortran/symbol.cc:2458 0x6f3ca3 gfc_find_derived_types(gfc_symbol*, gfc_namespace*, char const*, bool) ../../trunk.20210101/gcc/fortran/symbol.cc:2458 0x9e1686 gfc_match_varspec(gfc_expr*, int, bool, bool) ../../trunk.20210101/gcc/fortran/primary.cc:2246 0x9e1916 match_variable ../../trunk.20210101/gcc/fortran/primary.cc:4309 0x99a364 gfc_match(char const*, ...) ../../trunk.20210101/gcc/fortran/match.cc:1144
[Bug libstdc++/114721] New: libstdc++-v3/include/ext/codecvt_specializations.h: 2 * small performance tweeks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114721 Bug ID: 114721 Summary: libstdc++-v3/include/ext/codecvt_specializations.h: 2 * small performance tweeks Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Static analyser cppcheck says: 1. libstdc++-v3/include/ext/codecvt_specializations.h:142:5: performance: Function 'external_encoding()' should return member '_M_ext_enc' by const reference. [returnByReference] Source code is const std::string external_encoding() const { return _M_ext_enc; } 2. libstdc++-v3/include/ext/codecvt_specializations.h:134:5: performance: Function 'internal_encoding()' should return member '_M_int_enc' by const reference. [returnByReference] Duplicate.
[Bug libgcc/114689] [14 Regression] libgcc/config/m68k/fpgnulib.c:305: Suspicious coding ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114689 --- Comment #6 from David Binderman --- (In reply to Jakub Jelinek from comment #5) > And does > extern void g( int); > > void f( int mant, int sticky) > { > mant = mant >> 1 ; > mant = mant >> 1 | (mant & 1); > mant = mant >> 1 | (mant & 1) | (!!sticky); > mant = !!sticky; > mant = (mant & 1) | (!!sticky); > g( mant); > } > shut up those warnings? Yes.
[Bug libgcc/114689] [14 Regression] libgcc/config/m68k/fpgnulib.c:305: Suspicious coding ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114689 --- Comment #4 from David Binderman --- I tried this code: extern void g( int); void f( int mant, int sticky) { mant = mant >> 1 ; mant = mant >> 1 | (mant & 1); mant = mant >> 1 | (mant & 1) | !!sticky; mant = !!sticky; mant = (mant & 1) | !!sticky; g( mant); } Cppcheck says: $ ~/cppcheck/trunk/cppcheck --enable=all apr12a.cc apr12a.cc:8:32: style: Boolean result is used in bitwise operation. Clarify expression with parentheses. [clarifyCondition] mant = mant >> 1 | (mant & 1) | !!sticky; ^ apr12a.cc:10:20: style: Boolean result is used in bitwise operation. Clarify expression with parentheses. [clarifyCondition] mant = (mant & 1) | !!sticky; ^ so it appears to be the combination of bitwise operation (mant & 1) and the boolean result !!sticky.
[Bug libgcc/114689] New: [14 Regression] libgcc/config/m68k/fpgnulib.c:305: Suspicious coding ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114689 Bug ID: 114689 Summary: [14 Regression] libgcc/config/m68k/fpgnulib.c:305: Suspicious coding ? Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Static analyser cppcheck says: libgcc/config/m68k/fpgnulib.c:305:37: style: Boolean result is used in bitwise operation. Clarify expression with parentheses. [clarifyCondition] Source code is mant = mant >> 1 | (mant & 1) | !!sticky; Perhaps mant = (mant >> 1) | (mant & 1) | !!sticky; was intended. This problem doesn't exist in the source code of gcc-13.2
[Bug libstdc++/114680] New: libstdc++-v3/include/ext/mt_allocator.h:142: possible performance problem ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114680 Bug ID: 114680 Summary: libstdc++-v3/include/ext/mt_allocator.h:142: possible performance problem ? Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Static analyser cppcheck says: libstdc++-v3/include/ext/mt_allocator.h:142:26: performance: Function parameter '__t' should be passed by const reference. [passedByValue] Source code is _M_set_options(_Tune __t) AFAIK sizeof( _Tune) >= 6 * sizeof( size_t) + sizeof( bool), so it might well be worthwhile to take the advice of the static analyser.
[Bug fortran/113956] [14 Regression] ice in gfc_trans_pointer_assignment, at fortran/trans-expr.cc:10524
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113956 David Binderman changed: What|Removed |Added Summary|ice in |[14 Regression] ice in |gfc_trans_pointer_assignmen |gfc_trans_pointer_assignmen |t, at |t, at |fortran/trans-expr.cc:10524 |fortran/trans-expr.cc:10524 --- Comment #1 from David Binderman --- It looks like a regression from gcc-13.2: test $ ~/gcc/results.13.2.asan.ubsan/bin/gfortran -c -w ./Lower/pointer-assignments.f90 test $ ~/gcc/results.20240327.asan.ubsan/bin/gfortran -c -w ./Lower/pointer-assignments.f90 ./Lower/pointer-assignments.f90:54:8: 54 | p => x |1 internal compiler error: in gfc_trans_pointer_assignment, at fortran/trans-expr.cc:10539
[Bug middle-end/113396] [13/14 Regression] csmith: differences from -O2 to -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113396 --- Comment #19 from David Binderman --- gcc 12.3 seems to get it right: foundBugs $ ~/gcc/results.12.3.asan.ubsan/bin/gcc -w -O2 --param=max-inline-insns-auto=23 bug998.c && valgrind -q ./a.out checksum = 77A231E6 foundBugs $ ~/gcc/results.12.3.asan.ubsan/bin/gcc -w -O2 --param=max-inline-insns-auto=24 bug998.c && valgrind -q ./a.out checksum = 77A231E6 foundBugs $ ~/gcc/results.12.3.asan.ubsan/bin/gcc -w -O2 --param=max-inline-insns-auto=30 bug998.c && valgrind -q ./a.out checksum = 77A231E6 foundBugs $ ~/gcc/results.12.3.asan.ubsan/bin/gcc -w -O3 bug998.c && valgrind -q ./a.out checksum = 77A231E6 foundBugs $
[Bug middle-end/113396] [13/14 Regression] csmith: differences from -O2 to -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113396 --- Comment #18 from David Binderman --- (In reply to David Binderman from comment #17) > I tried out gcc-13.2 and got the following results: > > foundBugs $ ~/gcc/results.13.2.asan.ubsan/bin/gcc -w -O2 > --param=max-inline-insns-auto=23 bug998.c && valgrind -q ./a.out > checksum = 77A231E6 > foundBugs $ ~/gcc/results.13.2.asan.ubsan/bin/gcc -w -O2 > --param=max-inline-insns-auto=24 bug998.c && valgrind -q ./a.out > checksum = 130B5204 > foundBugs $ > > so it is something that has been going wrong since before gcc-13.2. Similarly with 13.1: foundBugs $ ~/gcc/results.13.1.asan.ubsan/bin/gcc -w -O2 --param=max-inline-insns-auto=23 bug998.c && valgrind -q ./a.out checksum = 77A231E6 foundBugs $ ~/gcc/results.13.1.asan.ubsan/bin/gcc -w -O2 --param=max-inline-insns-auto=24 bug998.c && valgrind -q ./a.out checksum = 130B5204 foundBugs $
[Bug middle-end/113396] [13/14 Regression] csmith: differences from -O2 to -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113396 --- Comment #17 from David Binderman --- I tried out gcc-13.2 and got the following results: foundBugs $ ~/gcc/results.13.2.asan.ubsan/bin/gcc -w -O2 --param=max-inline-insns-auto=23 bug998.c && valgrind -q ./a.out checksum = 77A231E6 foundBugs $ ~/gcc/results.13.2.asan.ubsan/bin/gcc -w -O2 --param=max-inline-insns-auto=24 bug998.c && valgrind -q ./a.out checksum = 130B5204 foundBugs $ so it is something that has been going wrong since before gcc-13.2.
[Bug middle-end/113396] [13/14 Regression] csmith: differences from -O2 to -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113396 --- Comment #16 from David Binderman --- (In reply to David Binderman from comment #15) > So it looks like one or more of the --param flags is to blame. foundBugs $ ~/gcc/results/bin/gcc -w -O2 bug998.c && ./a.out checksum = 77A231E6 foundBugs $ ~/gcc/results/bin/gcc -w -O2 --param=max-inline-insns-auto=30 bug998.c && ./a.out checksum = 130B5204 foundBugs $ It seems to break sometime between 23 and 24. foundBugs $ ~/gcc/results/bin/gcc -w -O2 --param=max-inline-insns-auto=23 bug998.c && ./a.out checksum = 77A231E6 foundBugs $ ~/gcc/results/bin/gcc -w -O2 --param=max-inline-insns-auto=24 bug998.c && ./a.out checksum = 130B5204 foundBugs $
[Bug middle-end/113396] [13/14 Regression] csmith: differences from -O2 to -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113396 --- Comment #15 from David Binderman --- (In reply to Jakub Jelinek from comment #14) > So, that is -O2 -fgcse-after-reload -fipa-cp-clone -floop-interchange > -floop-unroll-and-jam -fpeel-loops -fpredictive-commoning -fsplit-loops > -fsplit-paths -ftree-loop-distribution -ftree-partial-pre -funswitch-loops > -fvect-cost-model=dynamic -fversion-loops-for-strides > --param=max-inline-insns-auto=30 --param=early-inlining-insns=14 > --param=inline-heuristics-hint-percent=600 --param=inline-min-speedup=15 > --param=max-inline-insns-single=200 Thanks for that. None of the -f flags seems to affect anything. foundBugs $ cat flag.list --param=early-inlining-insns=14 --param=inline-heuristics-hint-percent=600 --param=inline-min-speedup=15 --param=max-inline-insns-auto=30 --param=max-inline-insns-single=200 -O2 foundBugs $ ~/gcc/results/bin/gcc -w -O2 bug998.c && ./a.out checksum = 77A231E6 foundBugs $ ~/gcc/results/bin/gcc -w `cat flag.list` bug998.c && ./a.out checksum = 130B5204 foundBugs $ So it looks like one or more of the --param flags is to blame.
[Bug middle-end/113396] [13/14 Regression] csmith: differences from -O2 to -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113396 --- Comment #13 from David Binderman --- I had another look at the original source code and got this with recent gcc trunk: foundBugs $ ~/gcc/results/bin/gcc -w bug998.c && ./a.out checksum = 77A231E6 foundBugs $ ~/gcc/results/bin/gcc -w -O2 bug998.c && ./a.out checksum = 77A231E6 foundBugs $ ~/gcc/results/bin/gcc -w -O3 bug998.c && ./a.out checksum = 130B5204 foundBugs $ ~/gcc/results/bin/gcc -w -O3 -fno-strict-aliasing -fno-loop-interchange bug998.c && ./a.out checksum = 130B5204 foundBugs $ ~/gcc/results/bin/gcc -w -O3 -fno-strict-aliasing -fno-loop-interchange bug998.c && valgrind -q ./a.out checksum = 130B5204 foundBugs $ ~/gcc/results/bin/gcc -w -O3 -fno-strict-aliasing -fno-loop-interchange -fsanitize=address bug998.c && ./a.out checksum = 77A231E6 foundBugs $ ~/gcc/results/bin/gcc -w -O3 -fno-strict-aliasing -fno-loop-interchange -fsanitize=undefined bug998.c && ./a.out checksum = 77A231E6 foundBugs $ Case 3 looks suspicious. I guess if I knew the which flags -O3 switches on, that aren't in -O2, I could find out which ones are causing trouble. I don't know a -O2.5 Case 4 makes it look like aliasing and loop interchange aren't at fault. Cases 5, 6 & 7 show that the usual tools find nothing wrong. Cases 6 & 7 make it looks like switching on a sanitizer makes the code work. I don't understand why that would be.
[Bug debug/108843] timeout with -g -O3 since r9-2635-g78ea9abc2018243a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108843 --- Comment #5 from David Binderman --- Created attachment 57711 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57711=edit C source code Another test case. foundBugs $ (ulimit -t 60; time ~/gcc/results/bin/gcc -c -w -O3 bug1023.c) real0m0.456s user0m0.435s sys 0m0.019s foundBugs $ (ulimit -t 60; time ~/gcc/results/bin/gcc -c -w -g -O3 bug1023.c) gcc: fatal error: Killed signal terminated program cc1 compilation terminated. real1m0.363s user0m59.555s sys 0m0.524s foundBugs $ (ulimit -t 60; time ~/gcc/results/bin/gcc -c -w -g -O3 -fno-var-tracking bug1023.c) real0m6.269s user0m5.620s sys 0m0.502s foundBugs $
[Bug c++/114297] New: Yet more problems with "definition in block does not dominate use in block"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114297 Bug ID: 114297 Summary: Yet more problems with "definition in block does not dominate use in block" Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- For this C++ code: void __assert_fail(char *, int, const char *) __attribute__((__noreturn__)); template void max(T, T); template struct SimpleVector { T array; int num; T *getRef(int i) { num - i ? void() : __assert_fail("", 7, __PRETTY_FUNCTION__); return + i; } }; struct Extremes { int minWidth; int maxWidth; }; int forceCalcColumnExtremes_cs; struct Table { SimpleVector colExtremes; void forceCalcColumnExtremes(); }; void Table::forceCalcColumnExtremes() { int minSumCols, maxSumCols; for (int i; i; ++i) { minSumCols += colExtremes.getRef(i)->minWidth; maxSumCols += colExtremes.getRef(i)->maxWidth; } max(forceCalcColumnExtremes_cs, minSumCols); max(forceCalcColumnExtremes_cs, maxSumCols); } compiled by recent gcc trunk, does this: cvise $ ~/gcc/results/bin/g++ -c -w -O3 bug1022.cc cvise $ ~/gcc/results/bin/g++ -c -w -O3 -march=znver3 bug1022.cc bug1022.cc: In member function ‘void Table::forceCalcColumnExtremes()’: bug1022.cc:20:6: error: definition in block 5 does not dominate use in block 3 20 | void Table::forceCalcColumnExtremes() { | ^ for SSA_NAME: vect_maxSumCols_16.16_76 in statement: vect_maxSumCols_16.16_90 = PHI PHI argument vect_maxSumCols_16.16_76 for PHI node vect_maxSumCols_16.16_90 = PHI during GIMPLE pass: vect bug1022.cc:20:6: internal compiler error: verify_ssa failed 0x159e432 verify_ssa(bool, bool) ../../trunk.20210101/gcc/tree-ssa.cc:1203 0x1204a9d execute_function_todo ../../trunk.20210101/gcc/passes.cc:2095 The bug first seems to occur sometime between g:71244316cf714725 and g:10cbfcd60f9e5bdb, which is a distance of 43 commits.
[Bug middle-end/105533] UBSAN: gcc/expmed.cc:3272:26: runtime error: signed integer overflow: -9223372036854775808 - 1 cannot be represented in type 'long int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105533 --- Comment #13 from David Binderman --- Seems fixed to me. I built a bootstrap with ASAN and UBSAN for languages C, C++ and Fortran and changed the usual -O2 for -O3 -march=znver3 and the bootstrap passed. I hadn't realised a bootstrap was such a good test of the compiler.
[Bug middle-end/105533] UBSAN: gcc/expmed.cc:3272:26: runtime error: signed integer overflow: -9223372036854775808 - 1 cannot be represented in type 'long int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105533 --- Comment #5 from David Binderman --- The problem with expmed.c happens with -O2 -march=znver3, so it's more prevalent than I thought. The problem with poly-int.h seems to require -O3. So they look like two separate problems.
[Bug middle-end/105533] UBSAN: gcc/expmed.cc:3272:26: runtime error: signed integer overflow: -9223372036854775808 - 1 cannot be represented in type 'long int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105533 --- Comment #3 from David Binderman --- Asan, most of the checking flags, fortran and the -march setting not required. Current configure script is: ../trunk.20210101/configure \ --disable-multilib \ --disable-werror \ --with-pkgversion=$HASH \ --with-build-config=bootstrap-ubsan \ --enable-checking=yes \ --enable-languages=c,c++ sed 's;-O2;-O3;' < Makefile > Makefile.tmp diff Makefile Makefile.tmp mv Makefile.tmp Makefile >From the output of the bootstrap: Configuring stage 2 in x86_64-pc-linux-gnu/libgcc ../../trunk.20210101/gcc/poly-int.h:1089:5: runtime error: left shift of negative value -8 ../../trunk.20210101/gcc/poly-int.h:1089:5: runtime error: left shift of negative value -8 ../../trunk.20210101/gcc/expmed.cc:3288:26: runtime error: signed integer overflow: -9223372036854775808 - 1 cannot be represented in type 'long int' Configuring stage 2 in x86_64-pc-linux-gnu/libgomp
[Bug middle-end/105533] UBSAN: gcc/expmed.cc:3272:26: runtime error: signed integer overflow: -9223372036854775808 - 1 cannot be represented in type 'long int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105533 David Binderman changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #2 from David Binderman --- I see something similar when attempting a bootstrap with asan & ubsan on current gcc trunk: gcc/expmed.cc:3288:26: runtime error: signed integer overflow: -9223372036854775808 - 1 cannot be represented in type 'long int' Configure is: ../trunk/configure \ --disable-multilib \ --disable-werror \ --with-build-config=bootstrap-asan \ --with-build-config=bootstrap-ubsan \ --enable-checking=df,extra,fold,rtl,yes \ --enable-languages=c,c++,fortran And there are extra flags added to the top level Makefile: sed 's;-O2;-O3 -march=native;' < Makefile > Makefile.tmp diff Makefile Makefile.tmp mv Makefile.tmp Makefile I wonder if this is a regression for gcc-14.
[Bug c/114239] New: ice: error: definition in block does not dominate use in block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114239 Bug ID: 114239 Summary: ice: error: definition in block does not dominate use in block Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- For this C code: int ip4_getbit_a, ip4_getbit_pos, ip4_clrbit_pos; void ip4_clrbit(int *a) { *a &= ip4_clrbit_pos; } typedef struct { char pxlen; int prefix } net_addr_ip4; void fib_get_chain(); int trie_match_longest_ip4(); int trie_match_next_longest_ip4(net_addr_ip4 *n) { int __trans_tmp_1; while (n->pxlen) { n->pxlen--; ip4_clrbit(>prefix); __trans_tmp_1 = ip4_getbit_a >> ip4_getbit_pos; if (__trans_tmp_1) return 1; } return 0; } void net_roa_check_ip4_trie_tab() { net_addr_ip4 px0; for (int _n = trie_match_longest_ip4(); _n; _n = trie_match_next_longest_ip4()) fib_get_chain(); } on x86_64, does this: $ ../results/bin/gcc -c -O3 -march=znver3 -w ~/cvise/bug1021.c /home/dcb38/cvise/bug1021.c: In function ‘net_roa_check_ip4_trie_tab’: /home/dcb38/cvise/bug1021.c:20:6: error: definition in block 19 does not dominate use in block 14 20 | void net_roa_check_ip4_trie_tab() { | ^~ for SSA_NAME: _117 in statement: px0__lsm.22_47 = PHI <_117(14), _117(19)> PHI argument _117 for PHI node px0__lsm.22_47 = PHI <_117(14), _117(19)> during GIMPLE pass: vect /home/dcb38/cvise/bug1021.c:20:6: internal compiler error: verify_ssa failed The bug first seems to occur sometime between g:1e74ce8983fd4926 and g:71244316cf714725, which is 42 commits.
[Bug tree-optimization/114234] [14 Regression] verify_ssa failure with early-break vectorisation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114234 David Binderman changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #1 from David Binderman --- For this C code: int ip4_getbit_a, ip4_getbit_pos, ip4_clrbit_pos; void ip4_clrbit(int *a) { *a &= ip4_clrbit_pos; } typedef struct { char pxlen; int prefix } net_addr_ip4; void fib_get_chain(); int trie_match_longest_ip4(); int trie_match_next_longest_ip4(net_addr_ip4 *n) { int __trans_tmp_1; while (n->pxlen) { n->pxlen--; ip4_clrbit(>prefix); __trans_tmp_1 = ip4_getbit_a >> ip4_getbit_pos; if (__trans_tmp_1) return 1; } return 0; } void net_roa_check_ip4_trie_tab() { net_addr_ip4 px0; for (int _n = trie_match_longest_ip4(); _n; _n = trie_match_next_longest_ip4()) fib_get_chain(); } on x86_64, does this: $ ../results/bin/gcc -c -O3 -march=znver3 -w ~/cvise/bug1021.c /home/dcb38/cvise/bug1021.c: In function ‘net_roa_check_ip4_trie_tab’: /home/dcb38/cvise/bug1021.c:20:6: error: definition in block 19 does not dominate use in block 14 20 | void net_roa_check_ip4_trie_tab() { | ^~ for SSA_NAME: _117 in statement: px0__lsm.22_47 = PHI <_117(14), _117(19)> PHI argument _117 for PHI node px0__lsm.22_47 = PHI <_117(14), _117(19)> during GIMPLE pass: vect /home/dcb38/cvise/bug1021.c:20:6: internal compiler error: verify_ssa failed The bug first seems to occur sometime between g:1e74ce8983fd4926 and g:71244316cf714725, which is 42 commits.
[Bug c++/114128] ice with -fstrub=internal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114128 --- Comment #2 from David Binderman --- (In reply to Richard Biener from comment #1) > incomplete bugreport Sorry, my mistake. I created a new one, when an old one is a better place. See # 112938 for more details.
[Bug middle-end/112938] ice with -fstrub=internal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112938 David Binderman changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #9 from David Binderman --- The reduced source code of comment 1 seems to compile ok, but the original attached source code doesn't.
[Bug middle-end/112938] ice with -fstrub=internal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112938 --- Comment #8 from David Binderman --- (In reply to Alexandre Oliva from comment #7) > Fixed. Seems to have reappeared: $ ~/gcc/results/bin/gcc -c -fstrub=internal bug988.cc bt2_locks.cpp: In function ‘void mcs_lock::spin_while_eq(const volatile std::atomic_bool&, bool)’: bt2_locks.cpp:36:1: error: invalid address operand in ‘mem_ref’ *expected; # VUSE <.MEM_8> expected.8_3 ={v} *expected; during IPA pass: strub bt2_locks.cpp:36:1: internal compiler error: verify_gimple failed 0x11f4a92 verify_gimple_in_cfg(function*, bool, bool) /home/dcb38/gcc/working/gcc/../../trunk.20210101/gcc/tree-cfg.cc:5663 0x1065788 execute_function_todo(function*, void*) /home/dcb38/gcc/working/gcc/../../trunk.20210101/gcc/passes.cc:2088 I would be grateful if someone could confirm what I am seeing here.
[Bug c++/114128] New: ice with -fstrub=internal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114128 Bug ID: 114128 Summary: ice with -fstrub=internal Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: ---
[Bug fortran/114102] New: ice in matching_typebound_op, at fortran/interface.cc:4564
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114102 Bug ID: 114102 Summary: ice in matching_typebound_op, at fortran/interface.cc:4564 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 57528 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57528=edit F90 source code >From the flang testsuite at https://github.com/llvm/llvm-project/tree/main/flang/test source code file ./Semantics/modfile35.f90, does this with recent gcc trunk: test $ ~/gcc/results/bin/gfortran -c -w ./Semantics/modfile35.f90 f951: internal compiler error: in matching_typebound_op, at fortran/interface.cc:4564 0x7768f6 matching_typebound_op(gfc_expr**, gfc_actual_arglist*, gfc_intrinsic_op, char const*, char const**) /home/dcb38/gcc/working/gcc/../../trunk.20210101/gcc/fortran/interface.cc:4564 This bug has existed since sometime before 20240126.
[Bug fortran/113956] New: ice in gfc_trans_pointer_assignment, at fortran/trans-expr.cc:10524
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113956 Bug ID: 113956 Summary: ice in gfc_trans_pointer_assignment, at fortran/trans-expr.cc:10524 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 57435 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57435=edit F90 source code >From the flang test suite at https://github.com/llvm/llvm-project/tree/main/flang/test, the file ./Lower/pointer-assignments.f90 does this: test $ ~/gcc/results/bin/gfortran -c -w ./Lower/dummy-procedure-character.f90 ./Lower/dummy-procedure-character.f90:183:4: 183 | function bar10(n) |1 internal compiler error: in gfc_get_symbol_decl, at fortran/trans-decl.cc:1629 0x861f00 gfc_get_symbol_decl(gfc_symbol*) /home/dcb38/gcc/working/gcc/../../trunk.20210101/gcc/fortran/trans-decl.cc:1629 0x8911b5 gfc_conv_variable(gfc_se*, gfc_expr*) /home/dcb38/gcc/working/gcc/../../trunk.20210101/gcc/fortran/trans-expr.cc:3049
[Bug fortran/107141] ICE: Segmentation fault (in contains_struct_check)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107141 David Binderman changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #4 from David Binderman --- Similar thing happens with file ./Lower/derived-type-finalization.f90 from the same test suite: test $ /home/dcb38/gcc/results.20240214.asan.ubsan/bin/gfortran -c -w ./Lower/derived-type-finalization.f90 ./Lower/derived-type-finalization.f90:227:37: 227 | allocate(up(10), source=copy(10)) | 1 internal compiler error: Segmentation fault 0xf55039 crash_signal(int) /home/dcb38/gcc/working/gcc/../../trunk.20210101/gcc/toplev.cc:317 0x87a0ab contains_struct_check(tree_node*, tree_node_structure_enum, char const*, int, char const*) ../../trunk.20210101/gcc/tree.h:3757
[Bug fortran/107143] ICE: 'verify_gimple' failed (Error: non-trivial conversion in 'mem_ref')
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107143 David Binderman changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #2 from David Binderman --- (In reply to Arseny Solokha from comment #0) > gfortran 13.0.0 20220925 snapshot > (g:77bbf69d2981dafc2ef3e59bfbefb645d88bab9d) ICEs when compiling the > following testcase w/ -fchecking, reduced from > test/Lower/forall/array-pointer.f90 from the flang 15.0.1 test suite: I can confirm that this is still happening on recent gfortran. test $ /home/dcb38/gcc/results.20240214.asan.ubsan/bin/gfortran -c -w ./Lower/forall/array-pointer.f90 ./Lower/forall/array-pointer.f90:486:13: 486 | subroutine s5(x,y,z,n1,n2) | ^ Error: non-trivial conversion in ‘mem_ref’ struct array02_integer(kind=4) struct array01_integer(kind=4) parm.85 = *_86; ./Lower/forall/array-pointer.f90:486:13: internal compiler error: ‘verify_gimple’ failed
[Bug fortran/113917] ice in gfc_class_vptr_get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113917 --- Comment #1 from David Binderman --- (In reply to David Binderman from comment #0) >The problem seems to exist since sometime before 2024016. That should be 20240116.
[Bug fortran/113917] New: ice in gfc_class_vptr_get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113917 Bug ID: 113917 Summary: ice in gfc_class_vptr_get Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 57420 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57420=edit F90 source code >From the flang test suite at https://github.com/llvm/llvm-project/tree/main/flang/test the file ./Lower/HLFIR/elemental-array-ops.f90 does this: test $ ~/gcc/results/bin/gfortran -c -w ./Lower/HLFIR/elemental-array-ops.f90 ./Lower/HLFIR/elemental-array-ops.f90:247:9: 247 | x = (y) | 1 internal compiler error: Segmentation fault 0xf58d89 crash_signal(int) /home/dcb38/gcc/working/gcc/../../trunk.20210101/gcc/toplev.cc:317 0x87ade1 gfc_class_vptr_get(tree_node*) /home/dcb38/gcc/working/gcc/../../trunk.20210101/gcc/fortran/trans-expr.cc:247 0x8944ea trans_class_vptr_len_assignment(stmtblock_t*, gfc_expr*, gfc_expr*, gfc_se*, tree_node**, tree_node**, tree_node**) with recent gfortran. The problem seems to exist since sometime before 2024016.
[Bug fortran/93814] [11/12/13/14 Regression] ICE in build_entry_thunks, at fortran/trans-decl.c:2898
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93814 David Binderman changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #11 from David Binderman --- >From the flang testsuite file ./Lower/HLFIR/bindc-entry-stmt.f90, these two should work: function foo() bind(c) character(1) :: foo, bar entry bar() bar = "a" end function and function foo2() character(1) :: foo2, bar2 entry bar2() bind(c) bar2 = "a" end function Instead, I get: internal compiler error: Segmentation fault 0xf580a9 crash_signal(int) /home/dcb38/gcc/working/gcc/../../trunk.20210101/gcc/toplev.cc:317 0x866511 build_entry_thunks(gfc_namespace*, bool) /home/dcb38/gcc/working/gcc/../../trunk.20210101/gcc/fortran/trans-decl.cc:0 0x866511 gfc_create_function_decl(gfc_namespace*, bool)
[Bug c/113902] New: ice in find_uses_to_rename_use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113902 Bug ID: 113902 Summary: ice in find_uses_to_rename_use Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- For this C source code: int g_66, g_80_2; void func_1func_41(int p_43) { lbl_1434: g_80_2 = 0; for (; g_80_2 <= 7; g_80_2 += 1) { g_66 = 0; for (; g_66 <= 7; g_66 += 1) if (p_43) goto lbl_1434; } } compiled by recent gcc trunk, does this: cvise $ ~/gcc/results/bin/gcc -c -O2 -march=znver3 bug1012.c during GIMPLE pass: vect bug1012.c: In function ‘func_1func_41’: bug1012.c:2:6: internal compiler error: Segmentation fault 2 | void func_1func_41(int p_43) { | ^ 0xed49f9 crash_signal(int) /home/dcb38/gcc/working/gcc/../../trunk.20210101/gcc/toplev.cc:317 0x106b7e8 find_uses_to_rename_use(basic_block_def*, tree_node*, bitmap_head**, b itmap_head*) /home/dcb38/gcc/working/gcc/../../trunk.20210101/gcc/tree-ssa-loop-manip .cc:414 The bug first seems to occur sometime between g:48207a5f00d6ae7c and g:39d989022dd0eacf.
[Bug c/113895] New: ice in in copy_reference_ops_from_ref, at tree-ssa-sccvn.cc:1144
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113895 Bug ID: 113895 Summary: ice in in copy_reference_ops_from_ref, at tree-ssa-sccvn.cc:1144 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- This C source code: int main_i; void transparent_crc(); #pragma pack(1) struct { signed : 17; signed : 6; unsigned : 13; unsigned f6 : 12 } g_20[]; void main() { transparent_crc(g_20[main_i].f6); } when compiled by recent gcc, does this: cvise $ ~/gcc/results/bin/gcc -c -O1 bug1011.c bug1011.c:9:1: warning: no semicolon at end of struct or union 9 | } g_20[]; | ^ bug1011.c:9:3: warning: array ‘g_20’ assumed to have one element 9 | } g_20[]; | ^~~~ during GIMPLE pass: fre bug1011.c: In function ‘main’: bug1011.c:10:1: internal compiler error: in copy_reference_ops_from_ref, at tree-ssa-sccvn.cc:1144 10 | void main() { transparent_crc(g_20[main_i].f6); } | ^~~~ 0x10e922a copy_reference_ops_from_ref(tree_node*, vec*) /home/dcb38/gcc/working/gcc/../../trunk.20210101/gcc/tree-ssa-sccvn.cc:1144 The bug first seems to appear sometime between g:48207a5f00d6ae7c and g:39d989022dd0eacf.
[Bug fortran/113885] New: ice in gimplify_expr, at gimplify.cc:18658
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113885 Bug ID: 113885 Summary: ice in gimplify_expr, at gimplify.cc:18658 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 57392 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57392=edit F90 source code The attached code, from the flang test suite, does this with recent gcc trunk: test $ ~/gcc/results/bin/gfortran -c -w ./Lower/HLFIR/elemental-call-with-finalization.f90 ./Lower/HLFIR/elemental-call-with-finalization.f90:27:13: 27 | x = elem(x) | ^ internal compiler error: in gimplify_expr, at gimplify.cc:18658 xb99d5e gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) /home/dcb38/gcc/working/gcc/../../trunk.20210101/gcc/gimplify.cc:18658 0xb857bd gimplify_stmt(tree_node**, gimple**) /home/dcb38/gcc/working/gcc/../../trunk.20210101/gcc/gimplify.cc:7480 0xb8fdd5 gimplify_modify_expr(tree_node**, gimple**, gimple**, bool) /home/dcb38/gcc/working/gcc/../../trunk.20210101/gcc/gimplify.cc:6377 0xb8fdd5 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) The flang test suite is at: https://github.com/llvm/llvm-project/tree/main/flang/test
[Bug fortran/113866] New: ice in generic_simplify_COND_EXPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113866 Bug ID: 113866 Summary: ice in generic_simplify_COND_EXPR Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 57380 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57380=edit F90 source code For this F90 source code file: ./Lower/HLFIR/bindc-assumed-length.f90 from the flang testsuite at https://github.com/llvm/llvm-project/tree/main/flang/test when compiled by recent gfortran, does this: est $ ~/gcc/results.20240210.asan.ubsan/bin/gfortran -c -w ./Lower/HLFIR/bindc-assumed-length.f90 ./Lower/HLFIR/bindc-assumed-length.f90:39:29: 39 | call bindc_optional(c1, c3) | 1 internal compiler error: Segmentation fault 0xf57d79 crash_signal(int) /home/dcb38/gcc/working/gcc/../../trunk.20210101/gcc/toplev.cc:317 0x17bdf2f generic_simplify_COND_EXPR(unsigned int, tree_code, tree_node*, tree_node*, tree_node*, tree_node*) /home/dcb38/gcc/working/gcc/generic-match-4.cc:0 0xaecbf8 fold_ternary_loc(unsigned int, tree_code, tree_node*, tree_node*, tree_node*, tree_node*) Here is a valgrind version of the same gfortran providing some clues: test $ ~/gcc/results.20240210.valgrind/bin/gfortran -c -w ./Lower/HLFIR/bindc-assumed-length.f90 ==3757741== Invalid read of size 2 ==3757741==at 0x17793EF: generic_simplify_COND_EXPR(unsigned int, tree_code, tree_node*, tree_node*, tree_node*, tree_node*) (generic-match-4.cc:10061) ==3757741==by 0xB082BB: fold_ternary_loc(unsigned int, tree_code, tree_node*, tree_node*, tree_node*, tree_node*) (fold-const.cc:13144)
[Bug fortran/113846] ice in fold_convert_loc, at fold-const.cc:2757
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113846 --- Comment #2 from David Binderman --- >From the same flang test suite, the following files seem to crash in the same routine: ./Lower/HLFIR/structure-constructor.f90 ./Lower/HLFIR/convert-mbox-to-value.f90 ./Lower/polymorphic-temp.f90 ./Lower/structure-constructors-alloc-comp.f90 It might be worth making sure any fix for this bug also fixes these four.
[Bug fortran/113846] New: ice in fold_convert_loc, at fold-const.cc:2757
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113846 Bug ID: 113846 Summary: ice in fold_convert_loc, at fold-const.cc:2757 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 57369 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57369=edit F90 source code >From the flang test suite at https://github.com/llvm/llvm-project/tree/main/flang/test, file ./Lower/HLFIR/elemental-polymorphic-merge.f90, does this with recent gfortran: test $ ~/gcc/results.20240208.asan.ubsan/bin/gfortran -c ./Lower/HLFIR/elemental-polymorphic-merge.f90 ./Lower/HLFIR/elemental-polymorphic-merge.f90:10:20: 10 | r = merge(x, y, m) |1 internal compiler error: in fold_convert_loc, at fold-const.cc:2757 0xac84c2 fold_convert_loc(unsigned int, tree_node*, tree_node*) /home/dcb38/gcc/working/gcc/../../trunk.20210101/gcc/fold-const.cc:2757 0x8ade4d gfc_conv_intrinsic_merge(gfc_se*, gfc_expr*) /home/dcb38/gcc/working/gcc/../../trunk.20210101/gcc/fortran/trans-intrinsic.cc:7589
[Bug fortran/113845] New: ice in gfc_get_array_ss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113845 Bug ID: 113845 Summary: ice in gfc_get_array_ss Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 57368 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57368=edit F90 source code >From the flang test suite at https://github.com/llvm/llvm-project/tree/main/flang/test, file ./Lower/HLFIR/elemental-intrinsics.f90 does this with recent gfortran: test $ ~/gcc/results.20240208.asan.ubsan/bin/gfortran -c -O1 ./Lower/HLFIR/elemental-intrinsics.f90 gfortran: internal compiler error: Segmentation fault signal terminated program f951 Please submit a full bug report, with preprocessed source (by using -freport-bug). See <https://gcc.gnu.org/bugs/> for instructions. test $ gdb on f951 says: #0 0x0228f236 in xcalloc (nelem=1, elsize=696) at ../../trunk.20210101/libiberty/xmalloc.c:158 #1 0x008588ec in gfc_get_array_ss ( next=0x3221ae8 , expr=0x9423af0, dimen=1, type=GFC_SS_SECTION) at ../../trunk.20210101/gcc/fortran/trans-array.cc:724 #2 gfc_walk_array_ref (ss=0x3221ae8 , expr=0x9423af0, ref=0x9423c20) at ../../trunk.20210101/gcc/fortran/trans-array.cc:11750 #3 0x00858cd8 in gfc_walk_elemental_function_args ( ss=0x3221ae8 , arg=0x9423a90, intrinsic_sym=0x77a66610, type=) at ../../trunk.20210101/gcc/fortran/trans-array.cc:12015
[Bug fortran/113823] ice in gfc_get_element_type, at fortran/trans-types.cc:1286
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113823 --- Comment #6 from David Binderman --- (In reply to Steve Kargl from comment #5) > That's not what I meant. There is no bug1006.f90 in > the llvm-project repo. What is the actual URL to the > actual testcase? It should look something like > > https://github.com/llvm/llvm-project/tree/main/flang/test/bug1006.f90 bug1006.f90 is my local file name for it. It is just a copy of the original file Lower/HLFIR/array-ctor-derived.f90 in the flang test suite. That has an URL of https://github.com/llvm/llvm-project/tree/main/flang/test/Lower/HLFIR/array-ctor-derived.f90
[Bug fortran/113823] ice in gfc_get_element_type, at fortran/trans-types.cc:1286
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113823 --- Comment #4 from David Binderman --- (In reply to kargl from comment #3) > If you do post the others, is it possible to include a URL to LLVM > repository? This will allow us to give proper credit for the code. https://github.com/llvm/llvm-project/
[Bug fortran/113823] ice in gfc_get_element_type, at fortran/trans-types.cc:1286
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113823 --- Comment #2 from David Binderman --- (In reply to kargl from comment #1) > (In reply to David Binderman from comment #0) > > > > This is the second ice from the flang test suite. > > If you're keep score > https://discourse.llvm.org/t/proposal-rename-flang-new-to-flang/69462/57 Interesting. Thanks. 32 more ice to be reported. There are probably some duplicates amongst that group. Hopefully I can report most or all of these before the next release.
[Bug fortran/113823] New: ice in gfc_get_element_type, at fortran/trans-types.cc:1286
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113823 Bug ID: 113823 Summary: ice in gfc_get_element_type, at fortran/trans-types.cc:1286 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 57355 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57355=edit F90 source code The attached F90 code does this with trunk: foundBugs $ ../results.20240206.asan.ubsan/bin/gfortran -c bug1006.f90 bug1006.f90:43:31: 43 | call takes_simple([s1, s2]) | 1 internal compiler error: in gfc_get_element_type, at fortran/trans-types.cc:1286 0x8f8b51 gfc_get_element_type(tree_node*) /home/dcb38/gcc/working/gcc/../../trunk.20210101/gcc/fortran/trans-types.cc:1286 This is the second ice from the flang test suite. bug1006.f90 is a copy of Lower/HLFIR/array-ctor-derived.f90.
[Bug c/113817] New: ice in move_early_exit_stmts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113817 Bug ID: 113817 Summary: ice in move_early_exit_stmts Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- For this C code: char enc_int_dst_orig; long main_val; char main_buf[20]; char *enc_int(char *dst, char *end, long value) { while (value) if (dst < end) *dst++ = value >>= 7; else return _int_dst_orig; *dst = 7; } void main() { enc_int(main_buf, main_buf + sizeof(main_buf), main_val); } compiles ok as follows: $ /home/dcb38/gcc/results.20240202.asan.ubsan/bin/gcc -c -O3 -march=znver3 ~/cvise/bug1005.c $ But a few days later: $ /home/dcb38/gcc/results.20240205.asan.ubsan/bin/gcc -c -O3 -march=znver3 ~/cvise/bug1005.c during GIMPLE pass: vect /home/dcb38/cvise/bug1005.c: In function ‘main’: /home/dcb38/cvise/bug1005.c:12:6: internal compiler error: Segmentation fault 12 | void main() { enc_int(main_buf, main_buf + sizeof(main_buf), main_val); } | ^~~~ 0xed44e9 crash_signal(int) /home/dcb38/gcc/working/gcc/../../trunk.20210101/gcc/toplev.cc:317 0x1186bd3 gsi_prev(gimple_stmt_iterator*) ../../trunk.20210101/gcc/gimple-iterator.h:236 0x1186bd3 move_early_exit_stmts(_loop_vec_info*) /home/dcb38/gcc/working/gcc/../../trunk.20210101/gcc/tree-vect-loop.cc:1 1804 $ /home/dcb38/gcc/results.20240202.asan.ubsan/bin/gcc -v 2>&1 | grep exp gcc version 14.0.1 20240202 (experimental) (639bd5e9b759a6d7) $ /home/dcb38/gcc/results.20240205.asan.ubsan/bin/gcc -v 2>&1 | grep exp gcc version 14.0.1 20240205 (experimental) (5b281946c4b51132) The git range is 40 commits.
[Bug fortran/113799] New: gfc_replace_expr: double free detected ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113799 Bug ID: 113799 Summary: gfc_replace_expr: double free detected ? Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 57350 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57350=edit F90 source code For the attached F90 source code, I get this test $ ~/gcc/results/bin/gfortran -c ./Evaluate/folding20.f90 free(): double free detected in tcache 2 f951: internal compiler error: Aborted 0xf581f9 crash_signal(int) /home/dcb38/gcc/working/gcc/../../trunk.20210101/gcc/toplev.cc:317 0x7658aa gfc_replace_expr(gfc_expr*, gfc_expr*) /home/dcb38/gcc/working/gcc/../../trunk.20210101/gcc/fortran/expr.cc:640 0x7658aa simplify_intrinsic_op(gfc_expr*, int) /home/dcb38/gcc/working/gcc/../../trunk.20210101/gcc/fortran/expr.cc:1324 0x7658aa gfc_simplify_expr(gfc_expr*, int) /home/dcb38/gcc/working/gcc/../../trunk.20210101/gcc/fortran/expr.cc:2317 The source code is from the flang testsuite in clang. The bug has existed since sometime before 20240107.
[Bug c++/113786] New: cppcheck: return value from find_if not properly checked ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113786 Bug ID: 113786 Summary: cppcheck: return value from find_if not properly checked ? Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Consider the following newish C++ code: #include #include #include int main() { auto is_even = [](int i) { return i % 2 == 0; }; for (auto const& w : {std::array{3, 1, 4}, {1, 3, 5}}) if (std::find_if(begin(w), end(w), is_even)) std::cout << "w contains an even number " << '\n'; else std::cout << "w does not contain even numbers\n"; } Here is static analyser cppcheck finding the problem with the find_if: bug1003.cc:11:13: warning: Suspicious condition. The result of find() is an iterator, but it is not properly checked. [stlIfFind] Recent Gcc and clang have little to say: Alphasrc $ ~/gcc/results/bin/g++ -g -O2 -Wall -Wextra -pedantic -D_FORTIFY_SOURCE=3 bug1003.cc Alphasrc $ ~/llvm/results/bin/clang++ -g -O2 -Wall -Wextra -pedantic -D_FORTIFY_SOURCE=3 bug1003.cc Alphasrc $ I guess any C++ STL function that returns something non-zero (in this case end(w) ) on error is liable to this problem. I found this problem in the source code of flang, the clang Fortran compiler, so it does occur in practice.
[Bug c/113727] csmith: differences from nothing to -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113727 --- Comment #11 from David Binderman --- Created attachment 57310 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57310=edit C source code
[Bug c/113727] csmith: differences from nothing to -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113727 --- Comment #10 from David Binderman --- (In reply to Sam James from comment #7) > Can you try produce a testcase without UB please? I have some partly reduced code that seems to have no UB. cvise $ ~/gcc/results/bin/gcc -w -fsanitize=address,undefined bug1002.c cvise $ ./a.out 1 > 0 cvise $ ~/gcc/results/bin/gcc -w -fsanitize=address,undefined -O1 bug1002.c cvise $ ./a.out 1 > 1 cvise $ diff 0 1 469c469 < ...checksum after hashing g_994.f3 : 5F99C263 --- > ...checksum after hashing g_994.f3 : 3D4A5D24 cvise $
[Bug c/113727] csmith: differences from nothing to -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113727 --- Comment #6 from David Binderman --- As expected: trunk.20210101 $ git bisect good 35b5bb475375dba4 6decda1a35be5764101987c210b5693a0d914e58 is the first bad commit commit 6decda1a35be5764101987c210b5693a0d914e58 Author: Richard Biener Date: Thu Oct 12 11:34:57 2023 +0200 tree-optimization/111779 - Handle some BIT_FIELD_REFs in SRA
[Bug c/113727] csmith: differences from nothing to -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113727 David Binderman changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #5 from David Binderman --- (In reply to David Binderman from comment #4) > Current range seems to be g:578aa2f80056175b .. g:328745607c5d403a, > some 155 commits. Current range seems to be g:0f40e59f193f96f1 to g:6decda1a35be5764. Of those 5 commits, 3 are for RISC-V and look unrelated and these two: g:6decda1a35be5764101987c210b5693a0d914e58 g:35b5bb475375dba4ea9101d6db13a6012c4e84ca look likely candidates, both by Richard. Adding Richard for their opinion. My first attempt at a reduction didn't work. I will have another go sometime over the weekend.
[Bug c/113727] csmith: differences from nothing to -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113727 --- Comment #4 from David Binderman --- (In reply to David Binderman from comment #3) > (In reply to David Binderman from comment #2) > > I have a bisection running too. I am trying out g:0f2e2080685e7509 > > That seems bad. Trying g:328745607c5d403a. Current range seems to be g:578aa2f80056175b .. g:328745607c5d403a, some 155 commits.
[Bug c/113727] csmith: differences from nothing to -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113727 --- Comment #3 from David Binderman --- (In reply to David Binderman from comment #2) > I have a bisection running too. I am trying out g:0f2e2080685e7509 That seems bad. Trying g:328745607c5d403a.
[Bug c/113727] csmith: differences from nothing to -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113727 --- Comment #2 from David Binderman --- I have a bisection running too. I am trying out g:0f2e2080685e7509
[Bug c/113727] New: csmith: differences from nothing to -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113727 Bug ID: 113727 Summary: csmith: differences from nothing to -O1 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 57298 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57298=edit C source code The attached C code seems to produce different answers between no optimisation flags and -O1: foundBugs $ ../results/bin/gcc -w bug1002.c foundBugs $ valgrind -q ./a.out 1 > 0 foundBugs $ ../results/bin/gcc -w -O1 bug1002.c foundBugs $ valgrind -q ./a.out 1 > 1 foundBugs $ diff 0 1 469,478c469,478 < ...checksum after hashing g_994.f3 : 5F99C263 < ...checksum after hashing g_994.f4 : 6E61EEE1 < ...checksum after hashing g_994.f5 : 8A4973F3 < ...checksum after hashing g_994.f6 : 1A47F5E1 < ...checksum after hashing g_994.f7 : CD2C240E < ...checksum after hashing g_994.f8 : 7E61A9F < ...checksum after hashing g_1368 : 74B15A31 < ...checksum after hashing g_1659 : 322B1FCB < ...checksum after hashing g_1720 : 65F2763C < checksum = 65F2763C --- > ...checksum after hashing g_994.f3 : 3D4A5D24 > ...checksum after hashing g_994.f4 : 23E1696C > ...checksum after hashing g_994.f5 : B115BFA4 > ...checksum after hashing g_994.f6 : E3A4BBDA > ...checksum after hashing g_994.f7 : D44B3E01 > ...checksum after hashing g_994.f8 : 656901A2 > ...checksum after hashing g_1368 : 3B45689 > ...checksum after hashing g_1659 : EBA715C1 > ...checksum after hashing g_1720 : BDD5FC31 > checksum = BDD5FC31 I have a reduction running. The bug first seems to occur sometime between dates 20231001 and 20231119. Git hashes are g:5f3da480e7541a9c and eaeaad3fcac4d7a3.
[Bug c++/81271] gcc/cp/lex.c:116: wrong condition ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81271 --- Comment #5 from David Binderman --- (In reply to Jason Merrill from comment #4) > What tool did this warning come from? Looks like cppcheck to me.
[Bug c/113561] New: yet more verify_ssa fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113561 Bug ID: 113561 Summary: yet more verify_ssa fails Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- For this C source code: char LZ4_decompress_generic_source; void LZ4_decompress_generic_endOnInput() { char *ip = _decompress_generic_source; while (1) { long length; if (length) { unsigned s; do { if (ip > -5) goto _output_error; s = *ip++; length += s; } while (s); } } _output_error: } cvise $ /home/dcb38/gcc/results.20240119.asan.ubsan/bin/gcc -c -w -O3 bug1001.c cvise $ /home/dcb38/gcc/results.20240119.asan.ubsan/bin/gcc -c -w -O3 -march=znver3 bug1001.c bug1001.c: In function ‘LZ4_decompress_generic_endOnInput’: bug1001.c:2:6: error: definition in block 7 does not dominate use in block 5 2 | void LZ4_decompress_generic_endOnInput() { | ^ The bug first seems to exist sometime between g:484f48f03cf9a382 and g:5a22bb250d8f4ad2
[Bug c/113555] Yet another failure in verify_ssa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113555 --- Comment #2 from David Binderman --- For the first source code, the bug seems to exist sometime between 20231119 and 20231227. Git hashes are g:eaeaad3fcac4d7a3 and g:f19ceb2d49afdfa5 Please ignore the second source code - it is a separate bug.
[Bug c/113555] Yet another failure in verify_ssa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113555 --- Comment #1 from David Binderman --- Second test case: char LZ4_decompress_generic_source; void LZ4_decompress_generic_endOnInput() { char *ip = _decompress_generic_source; while (1) { long length; if (length) { unsigned s; do { if (ip > -5) goto _output_error; s = *ip++; length += s; } while (s); } } _output_error: } cvise $ ~/gcc/results/bin/gcc -c -w -O3 bug1000B.c cvise $ ~/gcc/results/bin/gcc -c -w -O3 -march=znver3 bug1000B.c bug1000B.c: In function ‘LZ4_decompress_generic_endOnInput’: bug1000B.c:2:6: error: definition in block 7 does not dominate use in block 5 2 | void LZ4_decompress_generic_endOnInput() { | ^
[Bug c/113555] New: Yet another failure in verify_ssa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113555 Bug ID: 113555 Summary: Yet another failure in verify_ssa Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Today's gcc trunk says: $ ~/gcc/results.20240123.asan.ubsan/bin/gcc -c -O3 -w bug1000.c $ ~/gcc/results.20240123.asan.ubsan/bin/gcc -c -O3 -w -march=znver3 bug1000.c bug1000.c: In function ‘net_roa_check_ip4_trie_tab’: bug1000.c:20:6: error: definition in block 4 does not dominate use in block 5 20 | void net_roa_check_ip4_trie_tab() { | ^~ for SSA_NAME: vect__14.32_111 in statement: vect__14.32_112 = PHI PHI argument vect__14.32_111 for PHI node vect__14.32_112 = PHI during GIMPLE pass: vect bug1000.c:20:6: internal compiler error: verify_ssa failed Reduced source code is int ip4_getbit_a, ip4_getbit_pos, ip4_clrbit_pos; void ip4_clrbit(int *a) { *a &= ip4_clrbit_pos; } typedef struct { char pxlen; int prefix } net_addr_ip4; void fib_get_chain(); int trie_match_longest_ip4(); int trie_match_next_longest_ip4(net_addr_ip4 *n) { int __trans_tmp_1; while (n->pxlen) { n->pxlen--; ip4_clrbit(>prefix); __trans_tmp_1 = ip4_getbit_a >> ip4_getbit_pos; if (__trans_tmp_1) return 1; } return 0; } void net_roa_check_ip4_trie_tab() { net_addr_ip4 px0; for (int _n = trie_match_longest_ip4(); _n; _n = trie_match_next_longest_ip4()) fib_get_chain(); } The bug seems to have existed since at least 20231227. On a side note, 1000 bug reports and enhancement requests in 11 years.
[Bug other/94629] 10 issues located by the PVS-studio static analyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94629 --- Comment #29 from David Binderman --- (In reply to Martin Jambor from comment #28) > And is there already a bugzilla bug about these (or should I create one)? Done. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113528
[Bug c/113528] New: gcc-13 meets PVS-studio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113528 Bug ID: 113528 Summary: gcc-13 meets PVS-studio Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- The following article describes using static analyser PVS-studio to find potential problems in gcc-13. https://pvs-studio.com/en/blog/posts/cpp/1067/ It might be worth checking the ten problems listed. It might also be worth checking that gcc trunk has no new problems, compared to gcc-13.
[Bug other/94629] 10 issues located by the PVS-studio static analyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94629 --- Comment #27 from David Binderman --- The original article checked gcc-10. gcc-13 is checked in the following article: https://pvs-studio.com/en/blog/posts/cpp/1067/ I suspect it would be most unwise if any release of gcc after 13 introduced new bugs that were known to pvs-studio.
[Bug middle-end/113396] [13/14 Regression] csmith: differences from -O2 to -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113396 --- Comment #10 from David Binderman --- Created attachment 57117 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57117=edit C source code After many hours, cvise appears incapable of reducing the code much beyond this version.
[Bug middle-end/113396] [13/14 Regression] csmith: differences from -O2 to -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113396 David Binderman changed: What|Removed |Added CC||aldyh at redhat dot com --- Comment #8 from David Binderman --- As expected: $ git bisect good fc259b522c0f8b7bbca8e7adcd3da63330094a34 8c99e307b20c502e55c425897fb3884ba8f05882 is the first bad commit commit 8c99e307b20c502e55c425897fb3884ba8f05882 Author: Aldy Hernandez Date: Sat Jun 25 18:58:02 2022 -0400 Over to Aldy for their best opinion.
[Bug middle-end/113396] [13/14 Regression] csmith: differences from -O2 to -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113396 --- Comment #7 from David Binderman --- Current range seems to be g:54a5f478487a955c3ffaec3e9164a72599bc1cfb .. g:1edfc8f2d3307a3ffa077a605f432832d7715462, which is 4 commits. Of those 4, this one commit 8c99e307b20c502e55c425897fb3884ba8f05882 Author: Aldy Hernandez Date: Sat Jun 25 18:58:02 2022 -0400 looks a likely candidate.
[Bug middle-end/113396] [13/14 Regression] csmith: differences from -O2 to -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113396 --- Comment #6 from David Binderman --- Reduced bisect range seems to be g:2c11662391bafd74c9d19bf7626b7bcef41c1323 .. g:9e0d5db3e04afd2d030ace4ccb5c1af5e9f05a8f, which is 462 commits.
[Bug middle-end/113396] [13/14 Regression] csmith: differences from -O2 to -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113396 --- Comment #5 from David Binderman --- Bisect range seems to be g:e03a0a4d73a478928b26213363fa5dbb9fc8695f .. g:4e1914625dec4aa09a5671c6294e877dbf4518f5, which is 1850 commits. I will continue the bisection.
[Bug middle-end/113396] [13/14 Regression] csmith: differences from -O2 to -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113396 --- Comment #4 from David Binderman --- foundBugs $ ../results.20220116/bin/gcc -w -O2 bug998.c foundBugs $ ./a.out checksum = 77A231E6 foundBugs $ ../results.20220116/bin/gcc -w -O3 bug998.c foundBugs $ ./a.out checksum = 77A231E6 foundBugs $ ../results.20230205/bin/gcc -w -O2 bug998.c foundBugs $ ./a.out checksum = 77A231E6 foundBugs $ ../results.20230205/bin/gcc -w -O3 bug998.c foundBugs $ ./a.out checksum = 130B5204 foundBugs $ So it goes wrong sometime between g:90045c5df5b3c8853e7740fb72a11aead1c489bb and g:d042f118798ae0648b45f97e63b0e5ab7c82c8ef, a distance of 7403 commits.
[Bug c/113396] csmith: differences from -O2 to -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113396 --- Comment #3 from David Binderman --- Created attachment 57089 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57089=edit C source code Partly reduced C source code.
[Bug c/113396] csmith: differences from -O2 to -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113396 --- Comment #2 from David Binderman --- The bug seems to exist from sometime before g:d042f118798ae0648b45f97e63b0e5ab7c82c8ef, dated 20230205.
[Bug c/113396] csmith: differences from -O2 to -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113396 --- Comment #1 from David Binderman --- foundBugs $ ~/gcc/results/bin/gcc -w -O2 bug998.c -o two.exe foundBugs $ ~/gcc/results/bin/gcc -w -O3 bug998.c -o three.exe foundBugs $ ./two.exe 1 > two.out foundBugs $ ./three.exe 1 > three.out foundBugs $ diff two.out three.out | head -20 510,520c510,520 < ...checksum after hashing g_179.f2 : F8C8E936 < ...checksum after hashing g_179.f3 : 22C7AEC4 < ...checksum after hashing g_179.f4 : E057A6AE < ...checksum after hashing g_179.f5 : 494E34F0 < ...checksum after hashing g_179.f6 : 72F55A7C < ...checksum after hashing g_179.f7 : 9B53D63F < ...checksum after hashing g_179.f8 : DD10C49F < ...checksum after hashing g_179.f9 : 979E03A7 < ...checksum after hashing g_195 : 63EDBCE7 < ...checksum after hashing g_196 : C1F2B26B < ...checksum after hashing g_226[i][j] : 835FC1 --- > ...checksum after hashing g_179.f2 : A0B13872 > ...checksum after hashing g_179.f3 : A6EAB221 > ...checksum after hashing g_179.f4 : 744D7BAB > ...checksum after hashing g_179.f5 : 4D71F83C > ...checksum after hashing g_179.f6 : 54EDEE43 > ...checksum after hashing g_179.f7 : B280A60F > ...checksum after hashing g_179.f8 : ECCE643D foundBugs $
[Bug c/113396] New: csmith: differences from -O2 to -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113396 Bug ID: 113396 Summary: csmith: differences from -O2 to -O3 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 57082 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57082=edit C source code The attached Csmith generated code does this: foundBugs $ ~/gcc/results/bin/gcc -w bug998.c foundBugs $ valgrind -q ./a.out checksum = 77A231E6 foundBugs $ ~/gcc/results/bin/gcc -w -O2 bug998.c foundBugs $ valgrind -q ./a.out checksum = 77A231E6 foundBugs $ ~/gcc/results/bin/gcc -w -O3 bug998.c foundBugs $ valgrind -q ./a.out checksum = 130B5204 foundBugs $ ~/gcc/results/bin/gcc -w -O3 -fno-strict-aliasing -fno-loop-interchange bug998.c foundBugs $ valgrind -q ./a.out checksum = 130B5204 foundBugs $
[Bug tree-optimization/113373] [14 regression] ICE in verify_ssa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113373 --- Comment #3 from David Binderman --- Reduced C++ code seems to be: void __assert_fail(char *, char *, int, const char *) __attribute__((__noreturn__)); template struct asCArray { asCArray(int); T [](unsigned); T *array; int length; }; template T ::operator[](unsigned index) { index < length ? void() : __assert_fail("", "", 8, __PRETTY_FUNCTION__); return array[index]; } unsigned asCReaderTranslateFunction_bc_1; int asCReaderTranslateFunction_bcLength; void asCReaderTranslateFunction() { asCArray bcSizes(asCReaderTranslateFunction_bcLength); int offset, size; for (int num; offset--; num++) size += bcSizes[num]; asCReaderTranslateFunction_bc_1 = size; }
[Bug tree-optimization/113373] [14 regression] ICE in verify_ssa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113373 --- Comment #2 from David Binderman --- Reducing ...
[Bug tree-optimization/113374] [14 regression] ICE in find_uses_to_rename_use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113374 --- Comment #1 from David Binderman --- trunk.20210101 $ ~/gcc/results.20240112.asan.ubsan/bin/gcc -v 2>&1 | grep exp gcc version 14.0.0 20240112 (experimental) (72b3495dfdddc277) trunk.20210101 $ ~/gcc/results.20240113.asan.ubsan/bin/gcc -v 2>&1 | grep exp gcc version 14.0.1 20240113 (experimental) (34a827039fabcf24) trunk.20210101 $ git log 72b3495dfdddc277..34a827039fabcf24 | grep -c "^commit" 52 trunk.20210101 $
[Bug tree-optimization/113373] [14 regression] ICE in verify_ssa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113373 --- Comment #1 from David Binderman --- $ /home/dcb38/gcc/results.20231221.asan.ubsan/bin/g++ -v 2>&1 | grep exp gcc version 14.0.0 20231221 (experimental) (514ea1df444ca7f6) $ /home/dcb38/gcc/results.20231227.asan.ubsan/bin/g++ -v 2>&1 | grep expgcc version 14.0.0 20231227 (experimental) (f19ceb2d49afdfa5) $ git log 514ea1df444ca7f6..f19ceb2d49afdfa5 | grep -c "^commit" 83 $
[Bug c++/113374] New: new breakage in find_uses_to_rename_use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113374 Bug ID: 113374 Summary: new breakage in find_uses_to_rename_use Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 57070 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57070=edit C++ source code In the last 24 hours or so, the attached code seems to have broken: $ ~/gcc/results.20240112.asan.ubsan/bin/gcc -c -w -O3 -march=znver2 bug997.cc $ ~/gcc/results.20240113.asan.ubsan/bin/gcc -c -w -O3 -march=znver2 bug997.cc during GIMPLE pass: vect bug997.cc: In member function ‘Botan::BER_Decoder& Botan::BER_Decoder::decode(Botan::BigInt&, Botan::ASN1_Tag, Botan::ASN1_Tag)’: bug997.cc:26093:14: internal compiler error: Segmentation fault 26093 | BER_Decoder& BER_Decoder::decode(BigInt& out, | ^~~ 0x11e8ad9 crash_signal(int) ../../trunk.20210101/gcc/toplev.cc:317 0x1388e28 find_uses_to_rename_use(basic_block_def*, tree_node*, bitmap_head**, bitmap_head*)
[Bug c++/113373] New: ice in verify_ssa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113373 Bug ID: 113373 Summary: ice in verify_ssa Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 57069 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57069=edit C++ source code Still some fallout from recent gcc trunk changes. The attached code does this: foundBugs $ /home/dcb38/gcc/results.20231221.asan.ubsan/bin/g++ -c -w -O3 -march=znver3 bug996.cc foundBugs $ /home/dcb38/gcc/results.20231227.asan.ubsan/bin/g++ -c -w -O3 -march=znver3 bug996.cc ../sdk/angelscript/source/as_restore.cpp: In member function ‘void asCReader::TranslateFunction(asCScriptFunction*)’: ../sdk/angelscript/source/as_restore.cpp:2824:6: error: definition in block 453 does not dominate use in block 457 for SSA_NAME: _1244 in statement: size_1336 = PHI <_1244(457), 0(227)> PHI argument _1244 for PHI node size_1336 = PHI <_1244(457), 0(227)> during GIMPLE pass: vect ../sdk/angelscript/source/as_restore.cpp:2824:6: internal compiler error: verify_ssa failed
[Bug tree-optimization/113137] [14 regression] Failed bootstrap with -O3 -march=znver2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113137 --- Comment #14 from David Binderman --- (In reply to Tamar Christina from comment #13) > Patch submitted Two weeks have elapsed and the patch doesn't seem to appear in git. Is it perhaps stuck somewhere ?
[Bug target/113045] armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045 --- Comment #22 from David Binderman --- (In reply to Richard Earnshaw from comment #21) > commit e75b54a2d932929a9b2e940c5aad1ef33a86c008 > Author: Richard Earnshaw > Date: Thu Mar 22 17:54:55 2012 + > > * lex.c (search_line_fast): Provide Neon-optimized version for ARM. Is the optimization still worthwhile some 12 years later ?
[Bug tree-optimization/113178] [14 Regression] ice in find_uses_to_rename_use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113178 David Binderman changed: What|Removed |Added CC||tamar.christina at arm dot com --- Comment #4 from David Binderman --- Reduced range seems to be g:0994ddd86f9c3d82 to g:a657c7e3518fcfc7. All commits in this range are by Tamar.
[Bug tree-optimization/113178] [14 Regression] ice in find_uses_to_rename_use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113178 --- Comment #3 from David Binderman --- After some bisection, range seems to be g:2902300340928989 to g:ed60b2868abdb793, a range of 21 commits.
[Bug tree-optimization/113178] [14 Regression] ice in find_uses_to_rename_use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113178 --- Comment #2 from David Binderman --- The bug first seems to occur sometime between git:514ea1df444ca7f6 and git:f19ceb2d49afdfa5, a distance of 83 commits.
[Bug c++/113178] New: ice in find_uses_to_rename_use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113178 Bug ID: 113178 Summary: ice in find_uses_to_rename_use Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- This C++ source code: struct PixelWeight { int m_SrcStart; int m_Weights[]; }; struct CWeightTable { int *GetValueFromPixelWeight(PixelWeight *, int) const; }; char ContinueStretchHorz_dest_scan; struct CStretchEngine { bool ContinueStretchHorz(); CWeightTable m_WeightTable; }; int *CWeightTable::GetValueFromPixelWeight(PixelWeight *pWeight, int index) const { long __trans_tmp_1; if (index < pWeight->m_SrcStart) return __trans_tmp_1 ? >m_Weights[pWeight->m_SrcStart] : nullptr; } bool CStretchEngine::ContinueStretchHorz() { { PixelWeight pPixelWeights; int dest_g_m; for (int j; j; j++) { int pWeight = *m_WeightTable.GetValueFromPixelWeight(, j); dest_g_m += pWeight; } ContinueStretchHorz_dest_scan = dest_g_m; } } when compiled by recent gcc trunk, does this: cvise $ ~/gcc/results.20231227.asan.ubsan/bin/g++ -c -O3 -w bug995.cc cvise $ ~/gcc/results.20231227.asan.ubsan/bin/g++ -c -O3 -w -march=znver3 bug995.cc during GIMPLE pass: vect bug995.cc: In member function ‘bool CStretchEngine::ContinueStretchHorz()’: bug995.cc:19:6: internal compiler error: Segmentation fault 19 | bool CStretchEngine::ContinueStretchHorz() { | ^~ 0x11e1b39 crash_signal(int) ../../trunk.20210101/gcc/toplev.cc:316 0x1381b98 find_uses_to_rename_use(basic_block_def*, tree_node*, bitmap_head**, bitmap_head*) ../../trunk.20210101/gcc/tree-ssa-loop-manip.cc:414
[Bug c/113172] New: ice in move_early_exit_stmts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113172 Bug ID: 113172 Summary: ice in move_early_exit_stmts Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- For this C code: int tswchp_2; short cpy_buf[8]; void ts_endcmd() { int i = 0; for (; i < 8 && i < tswchp_2; i++) cpy_buf[i] = i; } compiled by recent gcc trunk, does this: cvise $ ~/gcc/results/bin/gcc -c -O3 bug994.c cvise $ ~/gcc/results/bin/gcc -c -O3 -march=znver3 bug994.c during GIMPLE pass: vect bug994.c: In function ‘ts_endcmd’: bug994.c:3:6: internal compiler error: Segmentation fault 3 | void ts_endcmd() { | ^ 0xeeade9 crash_signal(int) ../../trunk.20210101/gcc/toplev.cc:316 0x11a8e63 gsi_prev(gimple_stmt_iterator*) ../../trunk.20210101/gcc/gimple-iterator.h:236 0x11a8e63 move_early_exit_stmts(_loop_vec_info*) ../../trunk.20210101/gcc/tree-vect-loop.cc:11807
[Bug tree-optimization/113144] [14 regression] ICE when building dpkg-1.21.15 in verify_dominators (error: dominator of 9 should be 48, not 12)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113144 David Binderman changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #7 from David Binderman --- I see this one also, while building libmpg. foundBugs $ ../results/bin/gcc -c -w -O3 bug993.c foundBugs $ ../results/bin/gcc -c -w -O3 -march=znver3 bug993.c src/libmpg123/format.c: In function ‘enc_chan_fit’: src/libmpg123/format.c:188:12: error: dominator of 70 should be 206, not 3 src/libmpg123/format.c:188:12: error: dominator of 71 should be 206, not 3 during GIMPLE pass: vect src/libmpg123/format.c:188:12: internal compiler error: in verify_dominators, at dominance.cc:1194
[Bug tree-optimization/113137] [14 regression] Failed bootstrap with -O3 -march=znver2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113137 David Binderman changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #8 from David Binderman --- I see this one also in a build of package LFSC. $ ~/gcc/results/bin/gcc -c -w -O3 bug992.cc foundBugs $ ~/gcc/results/bin/gcc -c -w -O3 -march=znver2 bug992.cc /home/dcb38/rpmbuild/BUILD/LFSC-bbc1798864dbc328092356d4c01f02ddc39ea6bd/src/code.cpp: In function ‘Expr* read_code()’: /home/dcb38/rpmbuild/BUILD/LFSC-bbc1798864dbc328092356d4c01f02ddc39ea6bd/src/code.cpp:112:7: error: PHI node with wrong VUSE on edge from BB 114 112 | Expr *read_code() | ^ .MEM_824 = PHI <.MEM_1387(114)> expected .MEM_1042
[Bug target/113045] armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045 --- Comment #18 from David Binderman --- (In reply to Mark Wielaard from comment #17) > I am surprised valgrind memcheck doesn't produce more output, normally it > would tell you why & where it found the address invalid. The valgrind output I gave originally looks to be in the usual valgrind format to me. Perhaps you are assuming some other debugging tool like asan or ubsan ? > I assume somehow > valgrind memcheck believes it is reading past the end of a data buffer, > while the code assumes this is fine because it will mask off the bits it > won't use. valgrind doesn't normally produce an error for copying around un-initialised bytes. However, it will produce an error if those bytes are used in a decision like an if statement. Your unconfirmed assumption agrees with mine, though.
[Bug target/113045] armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045 --- Comment #15 from David Binderman --- (In reply to Jonathan Wakely from comment #12) > Because otherwise I'm going to get blamed for every bug older than > 2022-11-01! > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111270#c1 My apologies for this. AFAIK sheer fluke git produced your name twice. I have extended my local history out to 20210101, nearly three years. That should reduce the size of the problem and I now know where to get full history.
[Bug target/113045] armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113045 --- Comment #14 from David Binderman --- (In reply to Andrew Pinski from comment #9) > Does it work correctly without valgrind? Yes. No one has yet attempted to reproduce my results. vld1q_u8 is a 128 bit ARM hardware instruction. I assume that the requirements for this instruction are not being met in some way by some data. Maybe a short string ?
[Bug tree-optimization/113069] gimple-ssa-sccopy.cc:143:12: warning: private field 'curr_generation' is not used [-Wunused-private-field]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113069 David Binderman changed: What|Removed |Added CC||fkastl at suse dot cz --- Comment #1 from David Binderman --- git blame has this: cd794c39610 (Filip Kastl 2023-12-14 11:29:31 +0100 143) unsigned curr_generation = 0; Adding author for their opinion.
[Bug c/113069] New: gimple-ssa-sccopy.cc:143:12: warning: private field 'curr_generation' is not used [-Wunused-private-field]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113069 Bug ID: 113069 Summary: gimple-ssa-sccopy.cc:143:12: warning: private field 'curr_generation' is not used [-Wunused-private-field] Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- >From today's build of gcc trunk with clang: gcc $ grep curr_generation gimple-ssa-sccopy.cc unsigned curr_generation = 0; gcc $