This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Ping [IA-64] Work around thinko in 'x' constraint implementation

I'd like to ping this patch as it fixed an ICE visible on both ia64 linux and ia64 openvms.


On Mar 6, 2012, at 11:07 PM, Eric Botcazou wrote:

> We have a regression on one of the testcases of our internal testsuite on IA-64 
> with a 4.7-based compiler, which is of the form:
> test_vec_madd.adb: In function 'Test_Vec_Madd':
> test_vec_madd.adb:160:5: error: could not split insn
> (insn 887 4859 889 16 (set (reg:TI 158 f30 [orig:417 m ] [417])
>        (mem/c:TI (reg/f:DI 14 r14 [1025]) [0 S16 A128])) /gnu/lib/gcc/ia64-hp-
> openvms/4_7_0/adainclude/g-altcon.adb:277 125 {movti_internal}
>     (nil))
> +===========================GNAT BUG DETECTED==============================+
> | Pro 7.1.0w (20120221-head) (ia64-hp-openvms) GCC error:                  |
> | in final_scan_insn, at final.c:2716                                      |
> | Error detected around test_vec_madd.adb:160:5|
> The compiler aborts during the final pass because it couldn't split the insn.
> The pattern for movti_internal is:
> (define_insn_and_split "movti_internal"
>  [(set (match_operand:TI 0 "destination_operand" "=r,   *fm,*x,*f,  Q")
> 	(match_operand:TI 1 "general_operand"     "r*fim,r,  Q, *fOQ,*f"))]
>  "ia64_move_ok (operands[0], operands[1])"
>  "@
>   #
>   #
>   ldfp8 %X0 = %1%P1
>   #
>   #"
>  "reload_completed && !ia64_load_pair_ok(operands[0], operands[1])"
>  [(const_int 0)]
> The problem is that the operands satisfy ia64_load_pair_ok so the splitter
> cannot be invoked on them.  The root cause is a discrepancy between this
> predicate and how the 'x' constraint is interpreted.  The predicate uses
> FP_REGNO_P to check the destination and this returns true for %f30 (but would
> return false for the immediately following register %f31).  But recog 
> interprets the 'x' constraint as meaning that every hard register in the 
> destination must be in the FP_REGS class; now the mode is TImode so both %f30 
> and %f31 are taken into account and %f31 isn't in the FP_REGS class, so the 
> operand is rejected.
> AFAICS the problem dates back to the introduction of the code (r102463), so I'm 
> not sure that we want to rewrite it at this point.  That's why the attached 
> patch is a simple workaround that just avoid ICEing.
> Bootstrapped/regtested on IA-64/Linux, OK for the mainline?  Do we also want it 
> for 4.7.1 (I assume that some RA change makes the issue visible in 4.7.x)?
> 2012-03-06  Eric Botcazou  <>
> 	* config/ia64/ia64.c (ia64_load_pair_ok): Return 0 if the second member
> 	of the destination isn't also a FP_REGS register.
> -- 
> Eric Botcazou
> <p1.diff>

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]