This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
PA problem
- To: law at redhat dot com, gcc-bugs at gcc dot gnu dot org
- Subject: PA problem
- From: Richard Earnshaw <rearnsha at arm dot com>
- Date: Wed, 28 Feb 2001 14:05:14 +0000
- cc: Richard dot Earnshaw at arm dot com
- Organization: ARM Ltd.
- Reply-To: Richard dot Earnshaw at arm dot com
Jeff,
Whilst looking into a miscompilation we were seeing on the PA with 2.95.2,
I spotted the following in the current sources:
In the PA machine description we currently have:
(define_insn ""
[(set (match_operand:DF 0 "register_operand" "=f")
(plus:DF (mult:DF (match_operand:DF 1 "register_operand" "f")
(match_operand:DF 2 "register_operand" "f"))
(match_operand:DF 3 "register_operand" "f")))
(set (match_operand:DF 4 "register_operand" "=&f")
(mult:DF (match_dup 1) (match_dup 2)))]
"(! TARGET_SOFT_FLOAT && TARGET_PA_20
&& ! (reg_overlap_mentioned_p (operands[4], operands[1])
|| reg_overlap_mentioned_p (operands[4], operands[2])))"
"#"
[(set_attr "type" "fpmuldbl")
(set_attr "length" "8")])
Shouldn't there also be a non-overlap of op[4] with op[3]? After all, the
splitter modifies op[4] in the first emitted instruction, but doesn't use
op[3] until the second:
(define_split
[(set (match_operand:DF 0 "register_operand" "=f")
(plus:DF (mult:DF (match_operand:DF 1 "register_operand" "f")
(match_operand:DF 2 "register_operand" "f"))
(match_operand:DF 3 "register_operand" "f")))
(set (match_operand:DF 4 "register_operand" "=&f")
(mult:DF (match_dup 1) (match_dup 2)))]
"! TARGET_SOFT_FLOAT && TARGET_PA_20"
[(set (match_dup 4) (mult:DF (match_dup 1) (match_dup 2)))
(set (match_dup 0) (plus:DF (mult:DF (match_dup 1) (match_dup 2))
(match_dup 3)))]
"")
The patterns immediately after this example have a similar problem, I
think. As do others in the description.
R.