http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43590
Ramana Radhakrishnan changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Known to work|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43590
rsand...@gcc.gnu.org changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
K
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43590
--- Comment #5 from rsandifo at gcc dot gnu.org
2011-03-30 14:52:42 UTC ---
Author: rsandifo
Date: Wed Mar 30 14:52:38 2011
New Revision: 171729
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=171729
Log:
gcc/
2011-03-30 Richard Sandiford
--- Comment #4 from ramana at gcc dot gnu dot org 2010-04-08 22:57 ---
I think this is one more case of the ARM backend lying to the general
infrastructure.
We expand into ld4qav8hi which happens to be in this following form. Note if
you look at init_regs, there is no use of reg:XI 13
--- Comment #3 from ramana at gcc dot gnu dot org 2010-04-08 22:32 ---
Bah I know the problem . The base pattern is flawed. Testing a patch.
Ramana
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-04-08 22:17 ---
(In reply to comment #1)
> Hmm - so why is it that we add an initialization for reg:XI 136 with a
> const_int 0 in .175r.init_regs
Because init_reg thinks the psedu register 136 is used unitialized. In fact
that i
--- Comment #1 from ramana at gcc dot gnu dot org 2010-04-08 22:13 ---
Hmm - so why is it that we add an initialization for reg:XI 136 with a
const_int 0 in .175r.init_regs
adding initialization in test of reg 136 at in block 3 for insn 12.
(insn 91 11 12 3 /tmp/n.c:13 (set (reg:XI 136
--
ramana at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
GCC target trip
