Re: PR java/19285: Interfaces not initialized by static field access

[Andrew Haley <aph at redhat dot com>]

Bryce McKinlay writes:
 > Tom Tromey wrote:
 > 
 > >Anyway, I think the rule for incrementing the ABI version should be:
 > >
 > >* C++ ABI tracks the gcc version number, so is auto-incremented each
 > >  release.
 > >
 > >* The generated BC ABI version number should be incremented either
 > >  zero or one time between releases.  In particular it should only be
 > >  incremented the first time a non-backward-compatible change is made.
 > >  
 > >
 > Is this a flexible enough rule? Say we found some nasty bug in GCJ 4.0.2 
 > that could only be fixed by an ABI change in 4.0.3 (but of course old 
 > binaries that didn't hit the bug could still be supported). It would 
 > make sense in that scenario to be able to increment the BC version 
 > number for the 4.0.x series, and have 4.1 support both the old version 
 > IDs. The current version scheme doesn't really permit this. I think 
 > GCJ_BOOTSTRAP_LOADER_ADDITION also reduces our flexibility here. Perhaps 
 > we need an extra digit between GNUC_MINOR and the "additions" to allow 
 > for the possibility of increments within each GNUC_MINOR release.
 > 
 > On the other hand, hopefully that won't happen, and if it does we could 
 > always improvise something at the time.
 > 
 > 
 > >Bryce> How about something like this? Or would it be better to explicitly
 > >Bryce> define each different version somewhere?
 > >
 > >The compiler side of this looks reasonable to me.
 > >
 > >On the runtime side I would prefer the addition of a new define and
 > >explicit recognition of it.  I think it is better to be very clear
 > >than to try to micro-optimize this.
 > >  
 > >
 > OK, here's an updated patch.
 > 
 > Andrew, I still need approval for the compiler side.

OK.  As I've also changed the ABI on the branch it needs to go there too.

Andrew.