This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [bugs] Another ICE
- To: Jan Hubicka <jh at suse dot cz>
- Subject: Re: [bugs] Another ICE
- From: Graham Stott <grahams at redhat dot com>
- Date: Thu, 31 May 2001 17:31:57 +0100
- Cc: Egbert Eich <eich at suse dot de>, gcc-patches at gcc dot gnu dot org,patches at x86-64 dot org, rth at cygnus dot com, amacleod at redhat dot com,bugs at x86-64 dot org
- References: <15126.20392.667586.213222@deepthought.fra.suse.de> <20010531175112.F28764@atrey.karlin.mff.cuni.cz>
Jan Hubicka wrote:
>
> Content-Description: message body text
> >
> > Hi Honza,
> >
> > I got another ICE with yesterday evenings version of gcc :-((
> >
> > Egbert.
> >
> Hi,
> the bug is caused by gcse, that emits result of gen_move_insn and then update
> basic block info for last insn. In case gen_move_insn used sequence of insns,
> others are kept w/o any info.
>
> (hmm, ugly - perhaps we can avoid gcse from using the BASIC_BLOCK_FOR_INSN
> completely? I can't imagince case gcse is doing transformation and don't know
> basic block information and keeping that array up-to-date is expensive)
>
> Honza
>
I'm puzzled why doesn't set_block_for_new_insns DTRT because it is supposed to
handle a sequence. I think your change is just papering over a bug.
Looking at set_block_for_new_insns I see that it stop scanning backwards if it
finds a NOTE.
/* Scan the previous instructions setting the block number until we find
an instruction that has the block number set, or we find a note
of any kind. */
for (insn = PREV_INSN (insn); insn != NULL_RTX; insn = PREV_INSN (insn))
{
if (GET_CODE (insn) == NOTE)
break;
....
}
Would the generated sequence by any chance of had a NOTE?
Graham