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]

Re: [PATCH] gcc/reload.c: Initialize several arrays before use them in find_reloads()

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  <>

	* reload.c (find_reloads): Initialize several arrays before use

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

If we look at the zero_cost_loop_{start,end} patterns we have:

        (if_then_else (ne (match_operand:SI 0 "register_operand" "2")


        (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.

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.


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