RFC: BC-ABI and Old Verifier

Mon Jan 10 14:44:00 GMT 2005

Ranjit Mathew writes:
 > On 2005年1月10日 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.