This is the mail archive of the
mailing list for the GCC project.
Re: [Patch, GCC/Thumb-1]Mishandle the label type insn in function thumb1_reorg
- From: "Bin.Cheng" <amker dot cheng at gmail dot com>
- To: Terry Guo <terry dot guo at arm dot com>
- Cc: Richard Earnshaw <Richard dot Earnshaw at arm dot com>, gcc-patches List <gcc-patches at gcc dot gnu dot org>, Ramana Radhakrishnan <Ramana dot Radhakrishnan at arm dot com>
- Date: Fri, 4 Jul 2014 10:36:38 +0100
- Subject: Re: [Patch, GCC/Thumb-1]Mishandle the label type insn in function thumb1_reorg
- Authentication-results: sourceware.org; auth=none
- References: <000701cf84a1$1ed04340$5c70c9c0$ at arm dot com> <53A14E3C dot 7010208 at arm dot com> <000b01cf8ad5$f58b7be0$e0a273a0$ at arm dot com>
On Wed, Jun 18, 2014 at 10:16 AM, Terry Guo <firstname.lastname@example.org> wrote:
>> -----Original Message-----
>> From: Richard Earnshaw
>> Sent: Wednesday, June 18, 2014 4:31 PM
>> To: Terry Guo
>> Cc: email@example.com; Ramana Radhakrishnan
>> Subject: Re: [Patch, GCC/Thumb-1]Mishandle the label type insn in function
>> On 10/06/14 12:42, Terry Guo wrote:
>> > Hi There,
>> > The thumb1_reorg function use macro INSN_CODE to find expected
>> > 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
>> > labels and current label_insn is the first insn of basic block, the
>> > INSN_CODE(label_insn) could accidentally equal to
>> > 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 <firstname.lastname@example.org>
>> > * config/arm/arm.c (thumb1_reorg): Move to next basic block if the
>> > 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.
> Thanks for comments. The patch is updated and tested. No more ICE. Is this one OK?
The bug is also reported for 4.9 branch at
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?