This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: RFC: BC-ABI and Old Verifier
Ranjit Mathew writes:
> On Mon, 10 Jan 2005 14:14:06 +0000, Andrew Haley <aph@redhat.com> wrote:
> > Ranjit Mathew writes:
> > >
> > > How about making either -findirect-dispatch the default
> > > *or* resurrecting the old verifier for the non-BC-ABI
> > > case?
> >
> > That's what we do.
>
> ???
>
> BTW, why *isn't* BC-ABI the default? Even if
> can't quite guarantee the ABI to remain constant,
> it seems to resolve *quite* a few issues...
Sure, but it's not yet quite stable. It will be. 4.0 is something of
a BC "pre-release" for people to use.
Also, it's rather less efficient than the "old" ABI.
> > > The current situation would cause users unnecessary pain
> > > (e.g. PR 5537) so it should be resolved either one way
> > > or the other, or we risk having to listen to lots of
> > > user complaints when GCC 4.0 is released.
> > >
> > > With the BC-ABI merge, a lot of the old verifier was
> > > disabled/crippled (e.g. subroutine verification):
> > >
> > > http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/java/verify.c.diff?r1=1.66&r2=1.67&only_with_tag=MAIN
> > >
> > > If we can't quite make BC-ABI the default yet, we
> > > should revert verify.c to revision 1.65 (just before
> > > the BC-ABI merge).
> >
> > Pre-approved. There's no reason not to revert the old verifier to its
> > pre-merge state; it was only a temporary kludge.
>
> Ok. But were they all just kludges or were there
> genuine bug-fixes too? In particular, do you remember
> why you made the set of changes in the latter half
> of the diff above?
All the TYPE_DUMMY stuff is for binary compatibility, and we don't use
the old verifier with BC. All the types being in a TREE_LIST is also
for binary compatibility.
It's far better simply to revert the old verifier to pre-merge.
Andrew.