[Patch, GCC/Thumb-1]Mishandle the label type insn in function thumb1_reorg

[Bin.Cheng]

On Fri, Jul 4, 2014 at 10:44 AM, Ramana Radhakrishnan
<ramana.gcc@googlemail.com> wrote:
> On Fri, Jul 4, 2014 at 10:36 AM, Bin.Cheng <amker.cheng@gmail.com> wrote:
>> On Wed, Jun 18, 2014 at 10:16 AM, Terry Guo <terry.guo@arm.com> wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: Richard Earnshaw
>>>> Sent: Wednesday, June 18, 2014 4:31 PM
>>>> To: Terry Guo
>>>> Cc: gcc-patches@gcc.gnu.org; Ramana Radhakrishnan
>>>> Subject: Re: [Patch, GCC/Thumb-1]Mishandle the label type insn in function
>>>> thumb1_reorg
>>>>
>>>> On 10/06/14 12:42, Terry Guo wrote:
>>>> > Hi There,
>>>> >
>>>> > The thumb1_reorg function use macro INSN_CODE to find expected
>>>> instructions.
>>>> > But the macro INSN_CODE doesn't work for label type instruction. The
>>>> > INSN_CODE(label_insn) will return the label number. When we have a lot
>>>> of
>>>> > labels and current label_insn is the first insn of basic block, the
>>>> > INSN_CODE(label_insn) could accidentally equal to
>>>> CODE_FOR_cbranchsi4_insn
>>>> > in this case. This leads to ICE due to SET_SRC(label_insn) in subsequent
>>>> > code. In general we should skip all such improper insns. This is the purpose
>>>> > of attached small patch.
>>>> >
>>>> > Some failures in recent gcc regression test on thumb1 target are caused by
>>>> > this reason. So with this patch, all of them passed and no new failures. Is
>>>> > it ok to trunk?
>>>> >
>>>> > BR,
>>>> > Terry
>>>> >
>>>> > 2014-06-10  Terry Guo  <terry.guo@arm.com>
>>>> >
>>>> >      * config/arm/arm.c (thumb1_reorg): Move to next basic block if the
>>>> head
>>>> >      of current basic block isn't a proper insn.
>>>> >
>>>>
>>>> I think you should just test that "insn != BB_HEAD (bb)".  The loop
>>>> immediately above this deals with the !NON-DEBUG insns, so the logic is
>>>> confusing the way you've written it.
>>>>
>>>> R.
>>>>
>>>
>>> Thanks for comments. The patch is updated and tested. No more ICE. Is this one OK?
>>>
>>> BR,
>>> Terry
>>
>> Hi,
>> The bug is also reported for 4.9 branch at
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61712
>> As far as I checked, the ICE is also caused by label instruction as in
>> this message thread.
>> Since the fix is on trunk more than two weeks, could we back port it
>> to 4.9 branch?
>
> Yes, since there have been no other issues reported. Can either of you
> also update PR61544 with the fields for Known to Work and Known to
> fail setting a target milestone of GCC 4.9.1 rather than leaving these
> fields empty.


Done, I will back port it to 4.9 branch after 24 hours window.
Hopefully we can catch with 4.9.1 release.

Thanks,
bin