https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62151
amker at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62151
--- Comment #17 from amker at gcc dot gnu.org ---
Author: amker
Date: Mon Dec 22 10:25:10 2014
New Revision: 219008
URL: https://gcc.gnu.org/viewcvs?rev=219008&root=gcc&view=rev
Log:
PR rtl-optimization/62151
* combine.c (try_combine): N
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62151
--- Comment #16 from amker at gcc dot gnu.org ---
For calls of distribute_notes with from_insn != NULL, I kind of understand why
it is vulnerable, at least when handling REG_DEAD notes.
When we distribute REG_DEAD note of one register from FROM_I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62151
--- Comment #15 from bin.cheng ---
Hmm, words on tem_insn issue at the end of comment #12 isn't mature. It's more
complicated than that.
Turns out live range of register which is noted as DEAD in i1/i2 can be
extended because we propagate its u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62151
--- Comment #14 from amker at gcc dot gnu.org ---
Working on a patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62151
--- Comment #13 from bin.cheng ---
The check itself is suspicious too. Why do we want to check elim_i2/elim_i1
when distributing REG_DEAD note from i1?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62151
bin.cheng changed:
What|Removed |Added
CC||amker.cheng at gmail dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62151
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62151
--- Comment #10 from Segher Boessenkool ---
Author: segher
Date: Thu Oct 2 02:18:01 2014
New Revision: 215789
URL: https://gcc.gnu.org/viewcvs?rev=215789&root=gcc&view=rev
Log:
2014-10-01 Segher Boessenkool
gcc/
PR rtl-optimization/6215
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62151
--- Comment #9 from amker at gcc dot gnu.org ---
(In reply to Eric Botcazou from comment #8)
> > I will try to test a patch, meanwhile, I am wondering if any combine expert
> > has something to share.
>
> distribute_notes is certainly an endless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62151
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62151
--- Comment #7 from amker at gcc dot gnu.org ---
It's a combine pass issue and it happens on x86 too. Dump before combine pass
is fine as below.
30: r83:SI=0
71: flags:CC=cmp(r83:SI,0x1)
REG_DEAD r83:SI
72: {r83:SI=-ltu(flags:CC,0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62151
--- Comment #6 from amker at gcc dot gnu.org ---
(In reply to Richard Biener from comment #5)
> Note that probably also made a latent issue pop up.
Indeed. After preliminary investigation, I think this case reveals two latent
issues. The first
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62151
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62151
--- Comment #5 from Richard Biener ---
Note that probably also made a latent issue pop up.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62151
amker at gcc dot gnu.org changed:
What|Removed |Added
CC||amker at gcc dot gnu.org
--- C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62151
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62151
--- Comment #2 from Marek Polacek ---
Seems like with -fno-move-loop-invariants even gcc 4.9 miscompiles this.
18 matches
Mail list logo
