public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug target/43590] ICE in spill_failure, at reload1.c:2158
[not found] <bug-43590-4@http.gcc.gnu.org/bugzilla/>
@ 2011-03-30 14:58 ` rsandifo at gcc dot gnu.org
2011-03-30 15:15 ` rsandifo at gcc dot gnu.org
2013-08-05 20:45 ` ramana at gcc dot gnu.org
2 siblings, 0 replies; 8+ messages in thread
From: rsandifo at gcc dot gnu.org @ 2011-03-30 14:58 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43590
--- Comment #5 from rsandifo at gcc dot gnu.org <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 <richard.sandiford@linaro.org>
Ramana Radhakrishnan <ramana.radhakrishnan@linaro.org>
PR target/43590
* config/arm/neon.md (neon_vld3qa<mode>, neon_vld4qa<mode>): Remove
operand 1 and reshuffle the operands to match.
(neon_vld3<mode>, neon_vld4<mode>): Update accordingly.
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/neon.md
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/43590] ICE in spill_failure, at reload1.c:2158
[not found] <bug-43590-4@http.gcc.gnu.org/bugzilla/>
2011-03-30 14:58 ` [Bug target/43590] ICE in spill_failure, at reload1.c:2158 rsandifo at gcc dot gnu.org
@ 2011-03-30 15:15 ` rsandifo at gcc dot gnu.org
2013-08-05 20:45 ` ramana at gcc dot gnu.org
2 siblings, 0 replies; 8+ messages in thread
From: rsandifo at gcc dot gnu.org @ 2011-03-30 15:15 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43590
rsandifo@gcc.gnu.org <rsandifo at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rsandifo at gcc dot gnu.org
Known to fail| |
--- Comment #6 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> 2011-03-30 15:03:18 UTC ---
Fixed on trunk.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/43590] ICE in spill_failure, at reload1.c:2158
[not found] <bug-43590-4@http.gcc.gnu.org/bugzilla/>
2011-03-30 14:58 ` [Bug target/43590] ICE in spill_failure, at reload1.c:2158 rsandifo at gcc dot gnu.org
2011-03-30 15:15 ` rsandifo at gcc dot gnu.org
@ 2013-08-05 20:45 ` ramana at gcc dot gnu.org
2 siblings, 0 replies; 8+ messages in thread
From: ramana at gcc dot gnu.org @ 2013-08-05 20:45 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43590
Ramana Radhakrishnan <ramana at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Known to work| |4.7.0
Resolution|--- |FIXED
Assignee|ramana at gcc dot gnu.org |unassigned at gcc dot gnu.org
Target Milestone|--- |4.7.0
Known to fail| |4.6.4
--- Comment #7 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
Fixed 4.7.0 onwards.
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/43590] ICE in spill_failure, at reload1.c:2158
2010-03-30 4:25 [Bug target/43590] New: " rmansfield at qnx dot com
` (3 preceding siblings ...)
2010-04-08 22:33 ` ramana at gcc dot gnu dot org
@ 2010-04-08 22:58 ` ramana at gcc dot gnu dot org
4 siblings, 0 replies; 8+ messages in thread
From: ramana at gcc dot gnu dot org @ 2010-04-08 22:58 UTC (permalink / raw)
To: gcc-bugs
------- 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 136 before this point, thus
data flow assumes that insn 12 is using an uninitialized value in this process.
(insn 12 10 13 3 /tmp/n.c:13 (parallel [
(set (reg:XI 136 [ D.3722 ])
(unspec:XI [
(mem:XI (reg/v/f:SI 141 [ src ]) [0 S64 A64])
(reg:XI 136 [ D.3722 ])
(unspec:V8HI [
(const_int 0 [0x0])
] 191)
] 111))
Why do we need the reg:XI 136 inside the UNSPEC here ? We could very well do
without that in the UNSPEC because all we are saying is that an XImode value is
written to by the load from the memory location described . I'm not an expert
on the Neon backend and thus someone else who knows more about the Neon backend
should comment about this one.
Thus the patch that I am testing is as below which atleast seems to fix the ICE
and didn't show any other issues.
Index: neon.md
===================================================================
--- neon.md (revision 158138)
+++ neon.md (working copy)
@@ -4711,26 +4711,25 @@ (define_insn "neon_vld4<mode>"
)
(define_expand "neon_vld4<mode>"
- [(match_operand:XI 0 "s_register_operand" "=w")
- (match_operand:SI 1 "s_register_operand" "+r")
+ [(match_operand:XI 0 "s_register_operand" "")
+ (match_operand:SI 1 "s_register_operand" "")
(unspec:VQ [(const_int 0)] UNSPEC_VSTRUCTDUMMY)]
"TARGET_NEON"
{
- emit_insn (gen_neon_vld4qa<mode> (operands[0], operands[0],
+ emit_insn (gen_neon_vld4qa<mode> (operands[0],
operands[1], operands[1]));
- emit_insn (gen_neon_vld4qb<mode> (operands[0], operands[0],
+ emit_insn (gen_neon_vld4qb<mode> (operands[0],
operands[1], operands[1]));
DONE;
})
(define_insn "neon_vld4qa<mode>"
[(set (match_operand:XI 0 "s_register_operand" "=w")
- (unspec:XI [(mem:XI (match_operand:SI 3 "s_register_operand" "2"))
- (match_operand:XI 1 "s_register_operand" "0")
+ (unspec:XI [(mem:XI (match_operand:SI 2 "s_register_operand" "1"))
(unspec:VQ [(const_int 0)] UNSPEC_VSTRUCTDUMMY)]
UNSPEC_VLD4A))
- (set (match_operand:SI 2 "s_register_operand" "=r")
- (plus:SI (match_dup 3)
+ (set (match_operand:SI 1 "s_register_operand" "=r")
+ (plus:SI (match_dup 2)
(const_int 32)))]
"TARGET_NEON"
{
@@ -4740,7 +4739,7 @@ (define_insn "neon_vld4qa<mode>"
ops[1] = gen_rtx_REG (DImode, regno + 4);
ops[2] = gen_rtx_REG (DImode, regno + 8);
ops[3] = gen_rtx_REG (DImode, regno + 12);
- ops[4] = operands[2];
+ ops[4] = operands[1];
output_asm_insn ("vld4.<V_sz_elem>\t{%P0, %P1, %P2, %P3}, [%4]!", ops);
return "";
}
@@ -4749,12 +4748,11 @@ (define_insn "neon_vld4qa<mode>"
(define_insn "neon_vld4qb<mode>"
[(set (match_operand:XI 0 "s_register_operand" "=w")
- (unspec:XI [(mem:XI (match_operand:SI 3 "s_register_operand" "2"))
- (match_operand:XI 1 "s_register_operand" "0")
+ (unspec:XI [(mem:XI (match_operand:SI 2 "s_register_operand" "1"))
(unspec:VQ [(const_int 0)] UNSPEC_VSTRUCTDUMMY)]
UNSPEC_VLD4B))
- (set (match_operand:SI 2 "s_register_operand" "=r")
- (plus:SI (match_dup 3)
+ (set (match_operand:SI 1 "s_register_operand" "=r")
+ (plus:SI (match_dup 2)
(const_int 32)))]
"TARGET_NEON"
{
@@ -4764,7 +4762,7 @@ (define_insn "neon_vld4qb<mode>"
ops[1] = gen_rtx_REG (DImode, regno + 6);
ops[2] = gen_rtx_REG (DImode, regno + 10);
ops[3] = gen_rtx_REG (DImode, regno + 14);
- ops[4] = operands[2];
+ ops[4] = operands[1];
output_asm_insn ("vld4.<V_sz_elem>\t{%P0, %P1, %P2, %P3}, [%4]!", ops);
return "";
}
Also the constraints in this expander routine are probably superfluous and
could be corrected.
(define_expand "neon_vld4<mode>"
[(match_operand:XI 0 "s_register_operand" "=w")
(match_operand:SI 1 "s_register_operand" "+r")
(unspec:VQ [(const_int 0)] UNSPEC_VSTRUCTDUMMY)]
"TARGET_NEON"
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43590
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/43590] ICE in spill_failure, at reload1.c:2158
2010-03-30 4:25 [Bug target/43590] New: " rmansfield at qnx dot com
` (2 preceding siblings ...)
2010-04-08 22:17 ` pinskia at gcc dot gnu dot org
@ 2010-04-08 22:33 ` ramana at gcc dot gnu dot org
2010-04-08 22:58 ` ramana at gcc dot gnu dot org
4 siblings, 0 replies; 8+ messages in thread
From: ramana at gcc dot gnu dot org @ 2010-04-08 22:33 UTC (permalink / raw)
To: gcc-bugs
------- 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
----------------------------------------------------------------------------
AssignedTo|unassigned at gcc dot gnu |ramana at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
Last reconfirmed|2010-03-31 11:05:50 |2010-04-08 22:32:55
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43590
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/43590] ICE in spill_failure, at reload1.c:2158
2010-03-30 4:25 [Bug target/43590] New: " rmansfield at qnx dot com
2010-03-31 11:06 ` [Bug target/43590] " ramana at gcc dot gnu dot org
2010-04-08 22:13 ` ramana at gcc dot gnu dot org
@ 2010-04-08 22:17 ` pinskia at gcc dot gnu dot org
2010-04-08 22:33 ` ramana at gcc dot gnu dot org
2010-04-08 22:58 ` ramana at gcc dot gnu dot org
4 siblings, 0 replies; 8+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2010-04-08 22:17 UTC (permalink / raw)
To: gcc-bugs
------- 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 is the whole point of init_reg :).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43590
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/43590] ICE in spill_failure, at reload1.c:2158
2010-03-30 4:25 [Bug target/43590] New: " rmansfield at qnx dot com
2010-03-31 11:06 ` [Bug target/43590] " ramana at gcc dot gnu dot org
@ 2010-04-08 22:13 ` ramana at gcc dot gnu dot org
2010-04-08 22:17 ` pinskia at gcc dot gnu dot org
` (2 subsequent siblings)
4 siblings, 0 replies; 8+ messages in thread
From: ramana at gcc dot gnu dot org @ 2010-04-08 22:13 UTC (permalink / raw)
To: gcc-bugs
------- 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 [ D.3722 ])
(const_int 0 [0x0])) -1 (nil))
There's something fundamentally funny going on here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43590
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bug target/43590] ICE in spill_failure, at reload1.c:2158
2010-03-30 4:25 [Bug target/43590] New: " rmansfield at qnx dot com
@ 2010-03-31 11:06 ` ramana at gcc dot gnu dot org
2010-04-08 22:13 ` ramana at gcc dot gnu dot org
` (3 subsequent siblings)
4 siblings, 0 replies; 8+ messages in thread
From: ramana at gcc dot gnu dot org @ 2010-03-31 11:06 UTC (permalink / raw)
To: gcc-bugs
--
ramana at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
GCC target triplet|arm-unknown-linux-gnueabi |arm-unknown-linux-gnueabi,
| |arm-eabi
Keywords| |ice-on-valid-code
Known to fail| |4.4.3 4.5.0
Last reconfirmed|0000-00-00 00:00:00 |2010-03-31 11:05:50
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43590
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2013-08-05 20:45 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <bug-43590-4@http.gcc.gnu.org/bugzilla/>
2011-03-30 14:58 ` [Bug target/43590] ICE in spill_failure, at reload1.c:2158 rsandifo at gcc dot gnu.org
2011-03-30 15:15 ` rsandifo at gcc dot gnu.org
2013-08-05 20:45 ` ramana at gcc dot gnu.org
2010-03-30 4:25 [Bug target/43590] New: " rmansfield at qnx dot com
2010-03-31 11:06 ` [Bug target/43590] " ramana at gcc dot gnu dot org
2010-04-08 22:13 ` ramana at gcc dot gnu dot org
2010-04-08 22:17 ` pinskia at gcc dot gnu dot org
2010-04-08 22:33 ` ramana at gcc dot gnu dot org
2010-04-08 22:58 ` ramana at gcc dot gnu dot org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).