https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72488
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72488
--- Comment #15 from Richard Biener ---
Author: rguenth
Date: Thu Jan 19 12:02:43 2017
New Revision: 244625
URL: https://gcc.gnu.org/viewcvs?rev=244625=gcc=rev
Log:
2017-01-19 Richard Biener
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72488
--- Comment #14 from Richard Biener ---
Author: rguenth
Date: Thu Jan 19 12:00:42 2017
New Revision: 244623
URL: https://gcc.gnu.org/viewcvs?rev=244623=gcc=rev
Log:
2017-01-19 Richard Biener
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72488
--- Comment #13 from Richard Biener ---
Ah.
Setting value number of t34_9752(D) to t34_9752(D) (changed)
Setting value number of t42_9760(D) to t42_9760(D) (changed)
WARNING: Giving up with SCCVN due to SCC size 10003 exceeding 1
so we're
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72488
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #12 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72488
--- Comment #11 from Jeffrey A. Law ---
We have two different SSA_NAMEs where their SSA_NAME_INFO is the same pointer.
Thus modification range info by way of set_range_info changes the underlying
range on both SSA_NAMEs. From a debugging
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72488
--- Comment #10 from rguenther at suse dot de ---
On Wed, 18 Jan 2017, law at redhat dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72488
>
> --- Comment #9 from Jeffrey A. Law ---
> So, just to record some thoughts.
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72488
--- Comment #9 from Jeffrey A. Law ---
So, just to record some thoughts.
There's about a half-dozen patches, mostly from the August timeframe that will
make this bug go latent. The general theme across them is they change the
order in which we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72488
--- Comment #8 from Jeffrey A. Law ---
I've got a solid theory here. But it's too late to test and write up.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72488
--- Comment #7 from Jeffrey A. Law ---
I poked at this a bit yesterday (given the irreducible loops I've got some
concerns that jump threading might be involved). Whatever is going on, it is
highly sensitive to just about any codegen changes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72488
--- Comment #6 from rguenther at suse dot de ---
On Tue, 22 Nov 2016, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72488
>
> Jakub Jelinek changed:
>
>What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72488
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72488
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72488
--- Comment #4 from Richard Biener ---
-Os -fno-tree-sink -fno-tree-reassoc -fno-tree-loop-im -fno-tree-pre
-fdisable-tree-ifcombine -fno-tree-loop-optimize -fno-tree-forwprop
-fdisable-tree-vrp2 -fdisable-tree-phiopt3 -fdisable-tree-phiopt2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72488
--- Comment #3 from Richard Biener ---
-fdisable-tree-vrp1 "fixes" it (yes, the revision uncovered a latent bug).
VRP1
performs a lot of jump-threading thus it isn't very likely the culprit.
Program received signal SIGFPE, Arithmetic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72488
Richard Biener changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72488
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
17 matches
Mail list logo