This is the mail archive of the gcc-patches@gcc.gnu.org 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: Java segfault in predict.c

From: Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>
To: Richard Henderson <rth at redhat dot com>,Bryce McKinlay <bryce at waitaki dot otago dot ac dot nz>, gcc at gcc dot gnu dot org,gcc-patches at gcc dot gnu dot org
Date: Wed, 29 May 2002 22:08:31 +0200
Subject: Re: Java segfault in predict.c
References: <3CF4842F.8020802@waitaki.otago.ac.nz> <20020529085438.GA32472@atrey.karlin.mff.cuni.cz> <20020529104400.D4168@redhat.com> <20020529192907.GA28830@atrey.karlin.mff.cuni.cz> <20020529124922.B4276@redhat.com>

Hello.

> > > Again, this seems like a real opportunity to want to rely on
> > > monotonicly increasing indicies...
> > 
> > Why?
> 
> So that we don't have to search for the start, obviously. 
> It'll be the lowest numbered block.

But if you want this, it should be sufficient to put compact_blocks
to the begining of flow_loops_find (the loop discovery code does not
change basic blocks).

Zdenek

References:
- Re: Java segfault in predict.c
  - From: Zdenek Dvorak
- Re: Java segfault in predict.c
  - From: Richard Henderson
- Re: Java segfault in predict.c
  - From: Zdenek Dvorak
- Re: Java segfault in predict.c
  - From: Richard Henderson

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