[Bug c/115428] New: 3 * unused in today's build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115428 Bug ID: 115428 Summary: 3 * unused in today's build Product: gcc Version: 15.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 with clang: working $ grep Wunused /tmp/0 ../../trunk/gcc/analyzer/call-summary.cc:727:21: warning: unused variable 'summary_cast_reg' [-Wunused-variable] ../../trunk/gcc/range-op.cc:209:1: warning: unused function 'has_pointer_operand_p' [-Wunused-function] ../../trunk/gcc/value-relation.cc:207:24: warning: unused variable 'relation_to_code' [-Wunused-const-variable] working $ I've checked all three and they all look like candidates for deletion.
[Bug c/115414] New: Problems during GIMPLE pass: widening_mul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115414
Bug ID: 115414
Summary: Problems during GIMPLE pass: widening_mul
Product: gcc
Version: 15.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 code:
char __vsprintf_internal_string;
unsigned long __vsprintf_internal_maxlen, __vsprintf_internal_end;
void __vsprintf_internal() {
if (__builtin_add_overflow((unsigned long)__vsprintf_internal_string,
__vsprintf_internal_maxlen,
&__vsprintf_internal_end))
__vsprintf_internal_end = -1;
}
does this with recent gcc:
cvise $ ~/gcc/results/bin/gcc -c -w -O2 bug1037.c
bug1037.c: In function ‘__vsprintf_internal’:
bug1037.c:3:6: error: definition in block 4 follows the use
3 | void __vsprintf_internal() {
| ^~~
for SSA_NAME: _11 in statement:
# .MEM_6 = VDEF <.MEM_12>
__vsprintf_internal_end = _11;
during GIMPLE pass: widening_mul
bug1037.c:3:6: internal compiler error: verify_ssa failed
0x1169c74 verify_ssa(bool, bool)
/home/dcb40b/gcc/working/gcc/../../trunk/gcc/tree-ssa.cc:1203
The bug first seems to appear sometime between g:366d45c8d4911dc7
and g:ae91b5dd14920ff9, which is 41 commits.
Original unreduced code available on request.
[Bug debug/115386] ice with -g -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115386 --- Comment #9 from David Binderman --- I tried a release build and it seemed fine to me: foundBugs $ ../results.20240610.release/bin/gcc -c -w -g -O3 bug1034.c foundBugs $ I guess if both asan & ubsan together cause a stack overflow, it might be worthwhile checking if one of them without the other can do that.
[Bug debug/115386] ice with -g -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115386 --- Comment #7 from David Binderman --- (In reply to Richard Biener from comment #6) > Are you using a compiler with release checking? No, with asan & ubsan. I tried running cc1 under gdb and got this backtrace: #0 0x00b54615 in gt_ggc_mx_rtx_def (x_p=0x7fffe939bd00) at gtype-desc.cc:323 #1 0x00b54829 in gt_ggc_mx_rtx_def (x_p=) at gtype-desc.cc:940 #2 0x00b55405 in gt_ggc_mx_rtx_def (x_p=) at gtype-desc.cc:717 #3 0x00b55405 in gt_ggc_mx_rtx_def (x_p=) at gtype-desc.cc:717 #4 0x00b55405 in gt_ggc_mx_rtx_def (x_p=) at gtype-desc.cc:717 #5 0x00b55405 in gt_ggc_mx_rtx_def (x_p=) at gtype-desc.cc:717 That continues on for a depth of more than 1000 frames. Interestingly, the code compiles fine with a gcc built with valgrind. foundBugs $ ~/gcc/results.20240608.valgrind/bin/gcc -w -g -O3 bug1034.c foundBugs
[Bug fortran/107141] ICE: Segmentation fault (in contains_struct_check)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107141 --- Comment #7 from David Binderman --- (In reply to anlauf from comment #6) > Judging from the name of the testcase this could be a quite different issue. > > Please open a separate PR and attach the source there. Done. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115401
[Bug fortran/115401] New: valgrind error in gfc_class_len_get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115401 Bug ID: 115401 Summary: valgrind error in gfc_class_len_get Product: gcc Version: 15.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 58387 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58387=edit f90 source code >From the flang testsuite, file ./Lower/derived-type-finalization.f90 does this with recent flang built with valgrind: test $ /home/dcb40b/gcc/results.20240608.valgrind/bin/gfortran -c -w ./Lower/derived-type-finalization.f90 ==122289== Invalid read of size 8 ==122289==at 0x85EFD7: gfc_class_len_get(tree_node*) (trans-expr.cc:273) ==122289==by 0x87761D: trans_class_vptr_len_assignment(stmtblock_t*, gfc_expr*, gfc_expr*, gfc_se*, tree_node**, tree_node**, tree_node**) (trans-expr.cc:10170) ==122289==by 0x87A8B2: trans_class_assignment (trans-expr.cc:12006) ==122289==by 0x87A8B2: gfc_trans_assignment_1(gfc_expr*, gfc_expr*, bool, bool, bool, bool) (trans-expr.cc:12501) flang testsuite is at https://github.com/llvm/llvm-project/tree/main/flang/test/ Source code attached.
[Bug web/115391] Suggest add current size of git repository to git page
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115391 --- Comment #5 from David Binderman --- (In reply to Jonathan Wakely from comment #1) > You really shouldn't ever need to start again, you can just do: > > git fetch origin && git reset --hard origin/master Thanks for the tip. After more than four years use on this project, my command of git remains very rudimentary indeed, with frequent recourse to stackoverflow to try to fix what it's done. For reference, the previous SCM solution, SVN, I had complete mastery of in a few months. It did everything I needed. I am not expecting the gcc project to change SCM solution anytime soon.
[Bug web/115391] New: Suggest add current size of git repository to git page
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115391 Bug ID: 115391 Summary: Suggest add current size of git repository to git page Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- On the web page for git (gcc.gnu.org/git.html), it might be worth mentioning that the current git repository for mainline is about 3 million objects and about 1.2 Gig in size. This matters for those of us on slow internet connections when we do $ git clone git://gcc.gnu.org/git/gcc.git trunk when the messages from git get a bit cryptic and we have to start again with a clean trunk.
[Bug debug/115386] ice with -g -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115386 --- Comment #5 from David Binderman --- I tried a git bisect and got this: $ git bisect good 6fa4b0135439d64c 30cfdd6ff56972d9d1b9dbdd43a8333c85618775 is the first bad commit commit 30cfdd6ff56972d9d1b9dbdd43a8333c85618775 Author: Robin Dapp Date: Fri May 17 12:48:52 2024 +0200 RISC-V: Remove dead perm series code and document. which doesn't look very plausible ;-| I think someone else ought to have a go at a bit bisect and a reduce.
[Bug debug/115386] ice with -g -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115386 --- Comment #3 from David Binderman --- (In reply to Sam James from comment #1) > I think it runs out of stack. I tried running it under gdb, and all I got were lots of stack frames, so I agree with your best advice. It doesn't seem all that reducible under cvise. I only managed to get an 8% reduction after an hour's run.
[Bug c/115386] New: ice with -g -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115386 Bug ID: 115386 Summary: ice with -g -O3 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: --- Created attachment 58380 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58380=edit C source code The attached code does this with recent gcc trunk: foundBugs $ ../results/bin/gcc -c -w -g -O3 bug1034.c gcc: internal compiler error: Segmentation fault signal terminated program cc1 Please submit a full bug report, with preprocessed source (by using -freport-bug). See <https://gcc.gnu.org/bugs/> for instructions. foundBugs $ The bug first seems to occur sometime between git hash g:b6c6d5abf0d31c93 and g:30cfdd6ff56972d9, which is 37 commits.
[Bug fortran/115316] New: valgrind error in insert_parameter_exprs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115316 Bug ID: 115316 Summary: valgrind error in insert_parameter_exprs Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- For this F90 source code: ! RUN: %python %S/test_errors.py %s %flang_fc1 ! Check for semantic errors in ALLOCATE statements subroutine C933_a(b1, ca3, ca4, cp3, cp3mold, cp4, cp7, cp8, bsrc) ! If any allocate-object has a deferred type parameter, is unlimited polymorphic, ! or is of abstract type, either type-spec or source-expr shall appear. ! Only testing deferred type parameters here. type SomeType(k, l1, l2) integer, kind :: k = 1 integer, len :: l1 integer, len :: l2 = 3 character(len=l2+l1) str end type type B(l) integer, len :: l character(:), allocatable :: msg type(SomeType(4, l, :)), pointer :: something end type character(len=:), allocatable :: ca1, ca2(:) character(len=*), allocatable :: ca3, ca4(:) character(len=2), allocatable :: ca5, ca6(:) character(len=5) mold type(SomeType(l1=:,l2=:)), pointer :: cp1, cp2(:) type(SomeType(l1=3,l2=4)) cp1mold type(SomeType(1,*,:)), pointer :: cp3, cp4(:) type(SomeType(1,*,5)) cp3mold type(SomeType(l1=:)), pointer :: cp5, cp6(:) type(SomeType(l1=6)) cp5mold type(SomeType(1,*,*)), pointer :: cp7, cp8(:) type(SomeType(1, l1=3)), pointer :: cp9, cp10(:) type(B(*)) b1 type(B(:)), allocatable :: b2 type(B(5)) b3 type(SomeType(4, *, 8)) bsrc ! Expecting errors: need type-spec/src-expr !ERROR: Either type-spec or source-expr must appear in ALLOCATE when allocatable object has a deferred type parameters allocate(ca1) !ERROR: Either type-spec or source-expr must appear in ALLOCATE when allocatable object has a deferred type parameters allocate(ca2(4)) !ERROR: Either type-spec or source-expr must appear in ALLOCATE when allocatable object has a deferred type parameters allocate(cp1) !ERROR: Either type-spec or source-expr must appear in ALLOCATE when allocatable object has a deferred type parameters allocate(cp2(2)) !ERROR: Either type-spec or source-expr must appear in ALLOCATE when allocatable object has a deferred type parameters allocate(cp3) !ERROR: Either type-spec or source-expr must appear in ALLOCATE when allocatable object has a deferred type parameters allocate(cp4(2)) !ERROR: Either type-spec or source-expr must appear in ALLOCATE when allocatable object has a deferred type parameters allocate(cp5) !ERROR: Either type-spec or source-expr must appear in ALLOCATE when allocatable object has a deferred type parameters allocate(cp6(2)) !ERROR: Either type-spec or source-expr must appear in ALLOCATE when allocatable object has a deferred type parameters allocate(b1%msg) !ERROR: Either type-spec or source-expr must appear in ALLOCATE when allocatable object has a deferred type parameters allocate(b1%something) !ERROR: Either type-spec or source-expr must appear in ALLOCATE when allocatable object has a deferred type parameters allocate(b2%msg) !ERROR: Either type-spec or source-expr must appear in ALLOCATE when allocatable object has a deferred type parameters allocate(b2%something) !ERROR: Either type-spec or source-expr must appear in ALLOCATE when allocatable object has a deferred type parameters allocate(b3%msg) !ERROR: Either type-spec or source-expr must appear in ALLOCATE when allocatable object has a deferred type parameters allocate(b3%something) ! Nominal cases, expecting no errors allocate(character(len=5):: ca2(4)) allocate(character(len=5):: ca1) allocate(character*5:: ca1) allocate(ca2(4), MOLD = "abcde") allocate(ca2(2), MOLD = (/"abcde", "fghij"/)) allocate(ca1, MOLD = mold) allocate(ca2(4), SOURCE = "abcde") allocate(ca2(2), SOURCE = (/"abcde", "fghij"/)) allocate(ca1, SOURCE = mold) allocate(SomeType(l1=1, l2=2):: cp1, cp2(2)) allocate(SomeType(1,*,5):: cp3, cp4(2)) !OK, but segfaults gfortran allocate(SomeType(l1=1):: cp5, cp6(2)) allocate(cp1, cp2(2), mold = cp1mold) allocate(cp3, cp4(2), mold = cp3mold) allocate(cp5, cp6(2), mold = cp5mold) allocate(cp1, cp2(2), source = cp1mold) allocate(cp3, cp4(2), source = cp3mold) allocate(cp5, cp6(2), source = cp5mold) allocate(character(len=10):: b1%msg, b2%msg, b3%msg) allocate(SomeType(4, b1%l, 9):: b1%something) allocate(b2%something, source=bsrc) allocate(SomeType(4, 5, 8):: b3%something) ! assumed/explicit length do not need type-spec/mold allocate(ca3, ca4(4)) allocate(ca5, ca6(4)) allocate(cp7, cp8(2)) allocate(cp9, cp10(2)) end subroutine >From the flang testsuite at https://github.com/llvm/llvm-project/tree/main/fla
[Bug fortran/115315] New: valgrind error in gfc_simplify_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115315
Bug ID: 115315
Summary: valgrind error in gfc_simplify_expr
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: dcb314 at hotmail dot com
Target Milestone: ---
For this Fortran source code:
! RUN: %python %S/test_errors.py %s %flang_fc1
! Test section subscript
subroutine p1
real :: a(10,10)
real :: b(5,5)
real :: c
integer :: n
n = 2
b = a(1:10:n,1:n+3)
end
! Test substring
subroutine p2
type t1(n1,n2)
integer,kind :: n1,n2
integer :: c2(iachar('ABCDEFGHIJ'(n1:n1)))
end type
character :: a(10)
character :: b(5)
character :: c(0)
integer :: n
n = 3
b = a(n:7)
b = a(n+3:)
b = a(:n+2)
a(n:7) = b
a(n+3:) = b
a(:n+2) = b
n = iachar(1_'ABCDEFGHIJ'(1:1))
c = 'ABCDEFGHIJ'(1:0)
end
! Test pointer assignment with bounds
subroutine p3
integer, pointer :: a(:,:)
integer, target :: b(2,2)
integer :: n
n = 2
a(n:,n:) => b
a(1:n,1:n) => b
end
! Test pointer assignment to array element
subroutine p4
type :: t
real, pointer :: a
end type
type(t) :: x(10)
integer :: i
real, target :: y
x(i)%a => y
end subroutine
A recent valgrind version of gfortran does this:
test $ ~/gcc/results.20240530.valgrind/bin/gfortran -c -w
./Semantics/resolve49.f90
==1331074== Invalid read of size 2
==1331074==at 0x48513A0: memmove (vg_replace_strmem.c:1414)
==1331074==by 0x74F69F: gfc_simplify_expr(gfc_expr*, int) (expr.cc:2305)
==1331074==by 0x74F4FB: gfc_simplify_expr(gfc_expr*, int) (expr.cc:2265)
The source code file is from the flang testsuite at
https://github.com/llvm/llvm-project/tree/main/flang/test
[Bug fortran/107141] ICE: Segmentation fault (in contains_struct_check)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107141 --- Comment #5 from David Binderman --- Bit more detail from valgrind: /Lower/derived-type-finalization.f90 ==687074== Invalid read of size 8 ==687074==at 0x856D97: gfc_class_len_get(tree_node*) (trans-expr.cc:273) ==687074==by 0x86F37B: trans_class_vptr_len_assignment(stmtblock_t*, gfc_expr*, gfc_expr*, gfc_se*, tree_node**, tree_node**, tree_node**) (trans-expr.cc:10169)
[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
