https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108825
--- Comment #5 from David Binderman ---
(In reply to David Binderman from comment #4)
> git range now seems to be g:59ad8b684dd67e17 .. g:3b54cc9d04c2efb2,
> which is 103 commits.
git range now seems to be g:0cbb756fe9c8e13a ..
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108825
--- Comment #4 from David Binderman ---
git range now seems to be g:59ad8b684dd67e17 .. g:3b54cc9d04c2efb2,
which is 103 commits.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108825
--- Comment #3 from David Binderman ---
(In reply to David Binderman from comment #2)
> Trying revision 1191a412bb17a734.
Seems bad. Trying 59ad8b684dd67e17.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108825
--- Comment #2 from David Binderman ---
Trying revision 1191a412bb17a734.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108825
Bug ID: 108825
Summary: error during GIMPLE pass: unrolljam
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108721
--- Comment #3 from David Binderman ---
Created attachment 54471
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54471=edit
C source code
After a short reduction.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108718
--- Comment #11 from David Binderman ---
(In reply to Martin Liška from comment #10)
> However, I see a segfault that happens for the code snippet now.
In the compiler or the generated code ?
No crashes here. Are you running an asan+ubsan gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108718
--- Comment #9 from David Binderman ---
Created attachment 54463
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54463=edit
C source code
After a further hour of reduction, a partially reduced program.
cvise doesn't seem able to make
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108718
--- Comment #8 from David Binderman ---
(In reply to David Binderman from comment #7)
> After about 20 minutes of reduction, cvise started going the wrong way.
Second reduction now running, with better script:
/usr/bin/gcc -c -w bug883.c && \
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108657
--- Comment #14 from David Binderman ---
After five hours of reduction, cvise has:
crc32_tab[256];
unsigned crc32_context = 4294967295;
void crc32_byte(b) {
crc32_context = crc32_context >> 8 ^ crc32_tab[(crc32_context ^ b) & 255];
}
void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108657
--- Comment #13 from David Binderman ---
I tried adding flag 1 to the run of the two binaries. Here is
the bash history:
1003 gcc bug880.c
1004 ./a.out > /tmp/0
1005 ~/gcc/results/bin/gcc -w -O3 -ftrivial-auto-var-init=zero bug880.c -o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108718
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108718
--- Comment #4 from David Binderman ---
(In reply to Andrew Pinski from comment #3)
> This also changes with -fno-strict-aliasing ...
So does that mean that csmith is producing C code with UB and so
this bug isn't valid ?
It might also mean
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108721
Bug ID: 108721
Summary: csmith: really old bug with -O2
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108718
Bug ID: 108718
Summary: csmith: possible bad code with -O2
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108657
David Binderman changed:
What|Removed |Added
CC||rguenther at suse dot de
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108688
Bug ID: 108688
Summary: error: ‘bit_field_ref’ of non-mode-precision operand
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108657
--- Comment #10 from David Binderman ---
Bingo !
>From snapshot 20220703, with g:f3a5e75cb66dc96e, to 20220807, with
g:ef54eb74cab17737, it goes wrong.
Perhaps someone who has the git history would like to bisect this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108657
--- Comment #9 from David Binderman ---
Same thing, back to 20220807.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108657
--- Comment #8 from David Binderman ---
(In reply to David Binderman from comment #7)
> I will have a look at how to get at dates before the clone date.
I used snapshots instead. I tried 20221002, and got
$ ./results.20221002/bin/gcc -w -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108679
Bug ID: 108679
Summary: ice in modify_call, at ipa-param-manipulation.cc:656
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108657
--- Comment #7 from David Binderman ---
I can only go back as far as 20221028, when the git tree was installed.
$ /home/dcb36/gcc/results.20221028/bin/gcc -w -O3 -ftrivial-auto-var-init=zero
bug880.c
$ ./a.out
checksum = BCC02729
$
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108657
--- Comment #6 from David Binderman ---
(In reply to David Binderman from comment #5)
> (In reply to David Binderman from comment #0)
> > Also, the possible bug seems to have first occurred sometime before 20230103
>
> Also before 20221201:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108657
--- Comment #5 from David Binderman ---
(In reply to David Binderman from comment #0)
> Also, the possible bug seems to have first occurred sometime before 20230103
Also before 20221201:
$ /home/dcb36/gcc/results.20221201/bin/gcc -w -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108657
--- Comment #3 from David Binderman ---
(In reply to Andrew Pinski from comment #2)
> If I initialize __trans_tmp_13 explictly to 0, the issue goes away
$ fgrep trans_tmp_13 bug880.c
int64_t __trans_tmp_13;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108657
--- Comment #1 from David Binderman ---
Created attachment 54403
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54403=edit
C source code
After 90 minutes reduction, about 12% of the original is left.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108657
Bug ID: 108657
Summary: csmith: possible wrong checksum with -O3 and
-ftrivial-auto-var-init=zero
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108638
Bug ID: 108638
Summary: Another ice in decompose, at wide-int.h:984
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108596
--- Comment #7 from David Binderman ---
(In reply to Jakub Jelinek from comment #6)
> Fixed on the trunk so far.
linux-6.2-rc6 builds fine, when built with -O3.
Thanks for the quick fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108596
Bug ID: 108596
Summary: error: EDGE_CROSSING missing across section boundary
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88853
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102760
--- Comment #8 from David Binderman ---
(In reply to Andrew Pinski from comment #7)
> (In reply to David Binderman from comment #6)
> > I see very similar for this legal C code:
>
> That seems like a different issue, please file it seperately.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108547
Bug ID: 108547
Summary: ice in decompose, at wide-int.h:984 for -O2 with -Wall
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102760
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108523
--- Comment #16 from David Binderman ---
cvise produces:
int g_149, g_167, g_481;
main() {
int *l_1478 = _149;
*l_1478 ^= g_167;
lbl_1481:
for (;;) {
g_481 = 1;
for (; g_481; g_481 += 1) {
g_167 ^= *l_1478;
if (g_149)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108523
--- Comment #15 from David Binderman ---
(In reply to Richard Biener from comment #14)
> Fixed, but I'll see if somebody comes up with a reduced testcase.
I have a reduction running with cvise.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108523
David Binderman changed:
What|Removed |Added
CC||rguenther at suse dot de
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108523
--- Comment #7 from David Binderman ---
Git range now seems to be g:4d08c674b0114622 .. g:36cabc257dfb7dd4
which is 8 commits.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108523
--- Comment #6 from David Binderman ---
Git range now seems to be g:4d08c674b0114622 .. g:b2aa75ded65f8c02
which is a range of 33 commits.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108523
--- Comment #5 from David Binderman ---
Current range seems to be g:4d08c674b0114622 .. g:400d9fc1f0433611
which is 133 commits.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108523
--- Comment #4 from David Binderman ---
Seems to run fine in about 0.1 seconds with g:4d08c674b0114622,
dated 20221129.
That seems to be about 533 commits.
I'll have a go at a git bisect.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108523
--- Comment #3 from David Binderman ---
Problem seems to start sometime before git hash g:9b111debbfb79a0a,
dated 20221229.
I'll try a build of a month earlier.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108523
--- Comment #2 from David Binderman ---
Doesn't complete in 1200 seconds.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108523
--- Comment #1 from David Binderman ---
Also won't run to completion with a ulimit of 750 seconds.
Trying 1200 seconds.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108523
Bug ID: 108523
Summary: -O1 -fcode-hoisting causes long compilation time ?
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108482
--- Comment #11 from David Binderman ---
It looks to me like g:af96500eea72c674a5686b35c66202ef2bd9688f
is the culprit.
Over to Richard for their best advice.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108482
David Binderman changed:
What|Removed |Added
CC||rguenther at suse dot de
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108482
--- Comment #9 from David Binderman ---
(In reply to David Binderman from comment #8)
> Current range is about 151 revisions.
After a few more rounds, current range seems to be g:fbad7a74aaaddea3
to g:c16c40808331a029, some 10 commits.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108482
--- Comment #8 from David Binderman ---
(In reply to David Binderman from comment #7)
> (In reply to David Binderman from comment #6)
> > (In reply to David Binderman from comment #5)
> > > (In reply to David Binderman from comment #0)
> > > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108482
--- Comment #7 from David Binderman ---
(In reply to David Binderman from comment #6)
> (In reply to David Binderman from comment #5)
> > (In reply to David Binderman from comment #0)
> > > The bug seems to exist since sometime before
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108482
--- Comment #6 from David Binderman ---
(In reply to David Binderman from comment #5)
> (In reply to David Binderman from comment #0)
> > The bug seems to exist since sometime before g:02c031088ac0bbf7, dated
> > 20221220.
>
> I tried out a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108482
--- Comment #5 from David Binderman ---
(In reply to David Binderman from comment #0)
> The bug seems to exist since sometime before g:02c031088ac0bbf7, dated
> 20221220.
I tried out a revision from a month earlier, dated 2022-11-20,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108482
--- Comment #1 from David Binderman ---
Reduced code seems to be:
int g_30, g_261, g_263, func_1___trans_tmp_17;
int **g_120;
int *g_530;
void func_1() {
int *l_29 = _30;
*l_29 = 1;
g_263 = 0;
for (; g_263 <= 1; g_263 += 1) {
g_530
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108482
Bug ID: 108482
Summary: ice in expand_LOOP_DIST_ALIAS, at internal-fn.cc:2737
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86426
--- Comment #11 from David Binderman ---
Probably still broken. One for Jason ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108384
--- Comment #8 from David Binderman ---
(In reply to David Binderman from comment #4)
> I suspect a grep pattern could help guide the reduction.
> I tried a few patterns, but didn't make any real progress.
Using this pattern:
$ grep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108384
David Binderman changed:
What|Removed |Added
CC||mjambor at suse dot cz
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108384
--- Comment #6 from David Binderman ---
(In reply to David Binderman from comment #5)
> (In reply to David Binderman from comment #4)
> > Meanwhile, I try a bisection. Trying git hash g:0333892db367b2b9
>
> Seems good. Trying
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108384
--- Comment #5 from David Binderman ---
(In reply to David Binderman from comment #4)
> Meanwhile, I try a bisection. Trying git hash g:0333892db367b2b9
Seems good. Trying g:d3328df5f5c9908c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108384
--- Comment #4 from David Binderman ---
(In reply to David Binderman from comment #3)
> (In reply to Andrew Pinski from comment #2)
> > The code is undefined ...
> >
> > func_23(l_26[1]);
> >
> > func_23(struct S0 p_24, struct S0 p_25)
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108384
--- Comment #3 from David Binderman ---
(In reply to Andrew Pinski from comment #2)
> The code is undefined ...
>
> func_23(l_26[1]);
>
> func_23(struct S0 p_24, struct S0 p_25)
Interesting. It looks like the reduction has not preserved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108384
--- Comment #1 from David Binderman ---
Reduced C code seems to be:
struct S0 {
int f0;
short f1;
unsigned f2 : 7;
short f3
};
g_389;
static *func_23();
func_2() {
struct S0 l_26[] = {4, 5, 4, 6, 4, 5, 4, 6};
func_23(l_26[1]);
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108384
Bug ID: 108384
Summary: error: conversion of register to a different size in
‘view_convert_expr’
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108278
--- Comment #16 from David Binderman ---
(In reply to Richard Biener from comment #15)
> So this bug is fixed?
Jakub and I seem to think so. Good enough ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108278
--- Comment #14 from David Binderman ---
(In reply to Florian Weimer from comment #8)
> I believe the revert in 455acc43518744b89d6a795bbba5045bd228060b should have
> fixed this?
It looks to me like it does.
> I also brought up the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108278
--- Comment #13 from David Binderman ---
(In reply to David Binderman from comment #12)
> Let's try that out:
>
> g:d423e8dc59045d8f and g:fee53a3194c0d8b7
Seems to work. Good.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108278
--- Comment #12 from David Binderman ---
(In reply to Jakub Jelinek from comment #10)
> BTW, please use g: prefix for git hashes or r13-4989-g345dffd0d4ebff7 or
> r13-4989 styles, anything else is quite useless as it doesn't create
> hyperlinks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108278
--- Comment #7 from David Binderman ---
(In reply to David Binderman from comment #4)
> (In reply to David Binderman from comment #3)
> > Trying revision aeee4812442c996f in bisect.
>
> That seems fine, so trying 3b6cac2b44b384cd.
That seems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108278
David Binderman changed:
What|Removed |Added
CC||fweimer at redhat dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108278
--- Comment #5 from David Binderman ---
Another runtime bug, probably related:
../../trunk.d1/gcc/expmed.cc:3282:26: runtime error: signed integer overflow:
-9223372036854775808 - 1 cannot be represented in type 'long int'
I am not sure if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108278
--- Comment #4 from David Binderman ---
(In reply to David Binderman from comment #3)
> Trying revision aeee4812442c996f in bisect.
That seems fine, so trying 3b6cac2b44b384cd.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108278
--- Comment #3 from David Binderman ---
Trying revision aeee4812442c996f in bisect.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108278
--- Comment #1 from David Binderman ---
Reduced C++ code is
typedef int mbstate_t;
namespace std {
struct Trans_NS___cxx11_basic_string {
char *c_str();
};
template _Facet use_facet(int);
template struct __codecvt_abstract_base {
typedef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108278
Bug ID: 108278
Summary: runtime error with -O1 -Wall
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108136
Bug ID: 108136
Summary: Modula2 meets cppcheck
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: modula2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108135
Bug ID: 108135
Summary: Modula2 meets clang
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: modula2
Assignee:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108126
Bug ID: 108126
Summary: rust meets cppcheck
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rust
Assignee:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108110
--- Comment #10 from David Binderman ---
That's the bad revision.
ipa: Better way of applying both IPA-CP and IPA-SRA (PR 103227)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108110
--- Comment #9 from David Binderman ---
(In reply to David Binderman from comment #8)
> 803a91330bf20174 seems bad, so trying 095a13eda2caf684.
That seems bad, so trying 4834e9360f7bf42f.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108110
--- Comment #8 from David Binderman ---
803a91330bf20174 seems bad, so trying 095a13eda2caf684.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108110
David Binderman changed:
What|Removed |Added
CC||mjambor at suse dot cz
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108110
--- Comment #6 from David Binderman ---
(In reply to David Binderman from comment #5)
> That revision seems good. Trying 7450b25566b7a738.
Seems good. Trying 512098a3316f07d4.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108110
--- Comment #5 from David Binderman ---
That revision seems good. Trying 7450b25566b7a738.
For the reduced code, -march=zen3 not required.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108110
--- Comment #4 from David Binderman ---
Git bisect now running. Trying 15f04af347e3b65f.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108110
--- Comment #3 from David Binderman ---
Reduced C++ code seems to be:
namespace std {
template struct integral_constant {
static constexpr int value = __v;
};
using true_type = integral_constant;
using false_type = integral_constant;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108111
Bug ID: 108111
Summary: Rust meets clang
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rust
Assignee:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108110
--- Comment #1 from David Binderman ---
CPU is AMD Ryzen 7 5700G, so -march flag is zen3.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108110
Bug ID: 108110
Summary: ice in modify_call, at ipa-param-manipulation.cc:700
with -std=c++14 -O3 -march=native
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108047
David Binderman changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108047
--- Comment #2 from David Binderman ---
That worked fine, so trying 09c91caeb84e7c36.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108047
--- Comment #1 from David Binderman ---
I am having a go at a git bisect. Trying 892e8c520be37d0a.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108047
Bug ID: 108047
Summary: ice: unexpected expression of kind implicit_conv_expr
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107937
--- Comment #3 from David Binderman ---
The bug first seems to appear sometime between git hash 4d08c674b0114622
from yesterday and d0a3d55ae4a2656f, from today.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107937
Bug ID: 107937
Summary: ice in find_var_cmp_const, at
gimple-predicate-analysis.cc:257
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107826
Bug ID: 107826
Summary: ice during GIMPLE pass: slp
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107734
--- Comment #10 from David Binderman ---
(In reply to Andrew Pinski from comment #9)
> Fixed.
Thanks for that.
Would it ok to manually check all uses of sbitmap, to make sure they initialise
bits appropriately, or would it be better to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107734
--- Comment #6 from David Binderman ---
I am trying a bisect with git hash b4fca4fc70dc76cf.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107734
--- Comment #5 from David Binderman ---
I have reduced one of the test cases downto this code:
float val1f[][2], val2f[][2], chkf[][2];
foof_i;
foof() {
int j;
foof_i = 0;
for (; foof_i < 8; foof_i++) {
float tmp = val1f[foof_i][j] *
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107734
--- Comment #4 from David Binderman ---
A third:
./gcc.target/i386/pr61403.c
==749959== Conditional jump or move depends on uninitialised value(s)
==749959==at 0x11DFAE7: bitmap_set_bit (sbitmap.h:137)
==749959==by 0x11DFAE7:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107734
--- Comment #3 from David Binderman ---
Another test case:
./gcc.target/i386/pr53366-2.c
==41== Conditional jump or move depends on uninitialised value(s)
==41==at 0x11DFAE7: bitmap_set_bit (sbitmap.h:137)
==41==by
401 - 500 of 1079 matches
Mail list logo
