On Fri, Jul 4, 2014 at 10:44 AM, Ramana Radhakrishnan <ramana....@googlemail.com> wrote: > On Fri, Jul 4, 2014 at 10:36 AM, Bin.Cheng <amker.ch...@gmail.com> wrote: >> On Wed, Jun 18, 2014 at 10:16 AM, Terry Guo <terry....@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....@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
