https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80974
Michael Meissner changed:
What|Removed |Added
CC||meissner at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80974
Andrew Pinski changed:
What|Removed |Added
CC||hjl.tools at gmail dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80974
--- Comment #10 from Richard Biener ---
Author: rguenth
Date: Tue Jun 6 12:46:41 2017
New Revision: 248919
URL: https://gcc.gnu.org/viewcvs?rev=248919&root=gcc&view=rev
Log:
2017-06-06 Richard Biener
PR tree-optimization/80974
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80974
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80974
--- Comment #8 from Richard Biener ---
So the issue is indeed that we change side-band info on "leaders" to sth
optimistic later proved wrong during iteration but we do not undo this setting
(the lattice changes are not undone later but it is exp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80974
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80974
--- Comment #6 from Marc Glisse ---
The conditions and location are probably not right, but at least the testcase
passes, so this gives an idea of where the problem is.
--- tree-ssa-sccvn.c(revision 248859)
+++ tree-ssa-sccvn.c(working c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80974
--- Comment #5 from Marc Glisse ---
scc_vn_restore_ssa_info is called at the end of PRE, but we would need some
form of restoration after any iteration cycle at least (or maybe we shouldn't
have modified the information for h_11, I don't know).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80974
--- Comment #4 from Marc Glisse ---
During iteration 1 on some loop, we get
Setting value number of i_10 to h_11 (changed)
which becomes
Setting value number of i_10 to i_10 (changed)
in later iterations.
But the call to set_ssa_val_to(i_10,h_11)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80974
--- Comment #3 from Marc Glisse ---
According to the previous dump (crited1):
# RANGE [1, 9] NONZERO 15
h_11 = h_43 + 1;
but when we call get_nonzero_bits on h_11 in PRE, we get 7 ???
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80974
--- Comment #2 from Marc Glisse ---
Ah good, a testcase, thanks. Maybe we'll understand what was breaking spec now.
Transformation happens during PRE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80974
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
12 matches
Mail list logo
