On Mon, Feb 23, 2015 at 11:26 PM, Jeff Law wrote:
> On 02/22/15 02:02, Chen Gang S wrote:
>>
>> It is for Bug65117, after this fix, ".i" file can be passed compiling.
>>
>> - 'this_alternative_win' is not initialized before use it: for the
>> first looping 0, it initializes 'this_alternative_win[0]', but
>> 'did_match' may use 'this_alternative_win[2]'.
>>
>> - 'this_alternative' may be not initialized before using: it
>> initializes 'this_alternative[i]', but may use 'this_alternative[m]'
>> (m > i).
>>
>> - After reading through the code, arrays 'this_alternative_match_win',
>> 'this_alternative_offmemok', and 'this_alternative_earlyclobber' may
>> be not initialized either, so initialize them too.
>>
>> This issue is found by cross compiling xtensa Linux kernel with the
>> latest gcc5. And after this patch, it can cross compile xtensa Linux
>> kernel with allmodconfig, successfully.
>>
>>
>> 2015-02-22 Chen Gang <gang.chen.5...@gmail.com>
>>
>> * reload.c (find_reloads): Initialize several arrays before use
>> them.
>
>
> From the documentation for matching constraints:
>
> Moreover, the digit must be a
> smaller number than the number of the operand that uses it in the
> constraint.
>
>
> If we look at the zero_cost_loop_{start,end} patterns we have:
>
> (if_then_else (ne (match_operand:SI 0 "register_operand" "2")
>
> and
>
>
> (if_then_else (ne (match_operand:SI 0 "nonimmediate_operand" "2,2")
>
> Similarly for the loop_end pattern.
>
>
> Which violate the rule for matching constraints.
...and should never have worked at all...
> I'm confident that if the xtensa's patterns were fixed to abide by the rules
> for matching constraints the problem in reload would not occur.
Chen, perhaps a warming can be implemented for this in genrecog?
Ciao!
Steven
