This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug rtl-optimization/38931] New: Seg fault when getting instruction latency on a *movsi_1 with an MMX target register
- From: "nvachhar at google dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 21 Jan 2009 18:59:29 -0000
- Subject: [Bug rtl-optimization/38931] New: Seg fault when getting instruction latency on a *movsi_1 with an MMX target register
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
Calling insn_default_latency on the following RTL causes the compiler to
segfault.
(insn 75 73 77 2 y.ii:19 (set (reg:SI 30 mm1)
(const_int 0 [0x0])) 41 {*movsi_1} (nil))
The root cause of the problem seems to be in i386.md. Pasted below is a
snippet of the file describing the alternatives for the instruction:
(define_insn "*movsi_1"
[(set (match_operand:SI 0 "nonimmediate_operand"
"=r,m ,*y,*y,?rm,?*y,*x,*x,?r ,m ,?*Yi,*x")
(match_operand:SI 1 "general_operand"
"g ,ri,C ,*y,*y ,rm ,C ,*x,*Yi,*x,r ,m "))]
In this case, alternative 2 is selected (an MMX register destination and a
constant source). Later in the .md file, we see that this causes the
instruction to have attribute "type" equal to "mmxadd"
[(set (attr "type")
(cond [(eq_attr "alternative" "2")
(const_string "mmxadd")
(eq_attr "alternative" "3,4,5")
(const_string "mmxmov")
(eq_attr "alternative" "6")
(const_string "sselog1")
(eq_attr "alternative" "7,8,9,10,11")
(const_string "ssemov")
(match_operand:DI 1 "pic_32bit_operand" "")
(const_string "lea")
]
(const_string "imov")))
Finally, from much earlier in i386.md, there is code to set the attribute
"memory". Here is that code:
(define_attr "memory" "none,load,store,both,unknown"
(cond [(eq_attr "type" "other,multi,str")
(const_string "unknown")
(eq_attr "type" "lea,fcmov,fpspc")
(const_string "none")
(eq_attr "type" "fistp,leave")
(const_string "both")
(eq_attr "type" "frndint")
(const_string "load")
(eq_attr "type" "push")
(if_then_else (match_operand 1 "memory_operand" "")
(const_string "both")
(const_string "store"))
(eq_attr "type" "pop")
(if_then_else (match_operand 0 "memory_operand" "")
(const_string "both")
(const_string "load"))
(eq_attr "type" "setcc")
(if_then_else (match_operand 0 "memory_operand" "")
(const_string "store")
(const_string "none"))
(eq_attr "type" "icmp,test,ssecmp,ssecomi,mmxcmp,fcmp")
(if_then_else (ior (match_operand 0 "memory_operand" "")
(match_operand 1 "memory_operand" ""))
(const_string "load")
(const_string "none"))
(eq_attr "type" "ibr")
(if_then_else (match_operand 0 "memory_operand" "")
(const_string "load")
(const_string "none"))
(eq_attr "type" "call")
(if_then_else (match_operand 0 "constant_call_address_operand" "")
(const_string "none")
(const_string "load"))
(eq_attr "type" "callv")
(if_then_else (match_operand 1 "constant_call_address_operand" "")
(const_string "none")
(const_string "load"))
(and (eq_attr "type" "alu1,negnot,ishift1,sselog1")
(match_operand 1 "memory_operand" ""))
(const_string "both")
(and (match_operand 0 "memory_operand" "")
(match_operand 1 "memory_operand" ""))
(const_string "both")
(match_operand 0 "memory_operand" "")
(const_string "store")
(match_operand 1 "memory_operand" "")
(const_string "load")
(and (eq_attr "type"
"!alu1,negnot,ishift1,
imov,imovx,icmp,test,bitmanip,
fmov,fcmp,fsgn,
sse,ssemov,ssecmp,ssecomi,ssecvt,ssecvt1,sseicvt,sselog1,
sseiadd1,mmx,mmxmov,mmxcmp,mmxcvt")
(match_operand 2 "memory_operand" ""))
(const_string "load")
(and (eq_attr "type" "icmov,ssemuladd,sse4arg")
(match_operand 3 "memory_operand" ""))
(const_string "load")
]
(const_string "none")))
One will notice that none of the patterns match, however, when evaluating the
second to last pattern, it queries operand 2 which does not exist for this RTL
instruction. This directly leads to the segfault.
--
Summary: Seg fault when getting instruction latency on a *movsi_1
with an MMX target register
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: nvachhar at google dot com
GCC build triplet: i686-unknown-linux-gnu
GCC host triplet: i686-unknown-linux-gnu
GCC target triplet: i686-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38931