https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97315
Aldy Hernandez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97315
--- Comment #12 from CVS Commits ---
The master branch has been updated by Aldy Hernandez :
https://gcc.gnu.org/g:91ae6930ed4a87d7b8e25e10378388b3f0dc1729
commit r11-3718-g91ae6930ed4a87d7b8e25e10378388b3f0dc1729
Author: Aldy Hernandez
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97315
--- Comment #11 from CVS Commits ---
The master branch has been updated by Aldy Hernandez :
https://gcc.gnu.org/g:214d514fafcd78cd54e4a4aa9ae08c89abf9cc57
commit r11-3717-g214d514fafcd78cd54e4a4aa9ae08c89abf9cc57
Author: Aldy Hernandez
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97315
Andrew Macleod changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |amacleod at redhat dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97315
--- Comment #9 from rguenther at suse dot de ---
On October 7, 2020 5:35:02 PM GMT+02:00, amacleod at redhat dot com
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97315
>
>--- Comment #8 from Andrew Macleod ---
>(In reply to David
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97315
--- Comment #8 from Andrew Macleod ---
(In reply to David Binderman from comment #6)
> I get something similar with this test case:
>
> int a;
> void b() {
> if (a >= 2147483647)
> c(a + 1);
> }
This one is slightly different.
Still
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97315
--- Comment #7 from Andrew Macleod ---
OK, there are a couple of things at play in this PR.
The original problem isn't actually unreachable code. well, sort of.
The pass determines something is unreachable and changes the condition, which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97315
--- Comment #6 from David Binderman ---
I get something similar with this test case:
int a;
void b() {
if (a >= 2147483647)
c(a + 1);
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97315
--- Comment #5 from Richard Biener ---
(In reply to Richard Biener from comment #4)
> EVRP knows to "skip" unreachable edges. Not sure how you even "ask" EVRP
> for values in unreachable blocks? It's lattice does never reflect its state?
Also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97315
--- Comment #4 from Richard Biener ---
EVRP knows to "skip" unreachable edges. Not sure how you even "ask" EVRP for
values in unreachable blocks? It's lattice does never reflect its state?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97315
--- Comment #3 from Aldy Hernandez ---
(In reply to Alex Coplan from comment #1)
> Seeing a similar ICE with the following simple C testcase:
>
> int a;
> int b(signed char c, int d) { return c < 0 ? 0 : c >> d; }
> void e(void)
> {
> for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97315
--- Comment #2 from Aldy Hernandez ---
evrp and ranger disagree on the singleton range for _3 in the following stmt:
:
if (_3 != 1)
(gdb) ptg evrp_ret
0
(gdb) ptg ranger_ret
1
Which is interesting because BB5 is actually unreachable:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97315
Alex Coplan changed:
What|Removed |Added
CC||acoplan at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97315
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to work|
14 matches
Mail list logo
