https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108278
--- Comment #17 from Jakub Jelinek ---
We know the commit introduced UB on the compiler side, but what I don't
understand is why it triggered on the testcases you've provided. It surely
introduced UB when compiling libgcc/unwind-dw2.c or
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
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
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 #11 from Jakub Jelinek ---
Anyway, can't reproduce with current trunk (just stage1 built with
-fsanitize=undefined).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108278
--- Comment #10 from Jakub Jelinek ---
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
in bugzilla.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108278
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108278
--- Comment #8 from Florian Weimer ---
I believe the revert in 455acc43518744b89d6a795bbba5045bd228060b should have
fixed this?
I also brought up the initialization issue on the gcc list:
Default initialization of poly-ints
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 #2 from Andrew Pinski ---
Note the original testcase does (inside _M_max_size):
return std::size_t(0x7fffL) / sizeof(_Tp);
Which was reduced to just:
attach___trans_tmp_3 = 9223372036854775807 / 2;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108278
Andrew Pinski changed:
What|Removed |Added
Keywords||ice-on-valid-code
Blocks|
17 matches
Mail list logo
