This is the mail archive of the gcc-patches@gcc.gnu.org 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]

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


Ok.


r~


On 04/04/2012 03:34 AM, Tristan Gingold wrote:
> 
> I'd like to ping this patch as it fixed an ICE visible on both ia64 linux and ia64 openvms.
> 
> Tristan.
> 
> 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  <ebotcazou@adacore.com>
>>
>> 	* 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]