This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: PR java/19285: Interfaces not initialized by static field access
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.
Bryce
2005-05-12 Bryce McKinlay <mckinlay@redhat.com>
* decl.c (GCJ_CURRENT_BC_ABI_VERSION): Bump version ID.
2005-05-12 Bryce McKinlay <mckinlay@redhat.com>
* include/jvm.h (_Jv_CheckABIVersion): Accept GCJ 4.1 BC-ABI
version ID.
--- decl.c 12 May 2005 01:26:50 -0000 1.220
+++ decl.c 12 May 2005 23:13:29 -0000
@@ -68,12 +68,11 @@
loader. */
#define GCJ_BOOTSTRAP_LOADER_ADDITION 1
-/* The version of the BC ABI that we generate. At the moment we are
- compatible with what shipped in GCC 4.0. This must be kept in sync
- with parse_version(), libgcj, and reality (if the BC format
- changes, this must change. */
+/* The version ID of the BC ABI that we generate. This must be kept in
sync
+ with parse_version(), libgcj, and reality (if the BC format changes,
this
+ must change. */
#define GCJ_CURRENT_BC_ABI_VERSION \
- (4 * 10000 + 0 * 10 + GCJ_BINARYCOMPAT_ADDITION)
+ (4 * 10000 + 1 * 10 + GCJ_BINARYCOMPAT_ADDITION)
/* The ABI version number. */
tree gcj_abi_version;
--- include/jvm.h 29 Apr 2005 18:35:36 -0000 1.84
+++ include/jvm.h 12 May 2005 23:08:14 -0000
@@ -566,17 +569,18 @@
#define GCJ_VERSION (__GNUC__ * 10000 + __GNUC_MINOR__ * 10)
#define GCJ_BINARYCOMPAT_ADDITION 5
-// At present we know we are compatible with the BC ABI as used in GCC
-// 4.0.
+// We know we are compatible with the following BC-ABI versions.
#define GCJ_40_BC_ABI_VERSION (4 * 10000 + 0 * 10 +
GCJ_BINARYCOMPAT_ADDITION)
+#define GCJ_41_BC_ABI_VERSION (4 * 10000 + 1 * 10 +
GCJ_BINARYCOMPAT_ADDITION)
inline bool
_Jv_CheckABIVersion (unsigned long value)
{
// Recognize our defined C++ ABI.
return (value == GCJ_VERSION
- // At the moment this is the only BC ABI we recognize.
- || value == GCJ_40_BC_ABI_VERSION);
+ // At present we are compatible with two known BC ABI versions.
+ || value == GCJ_40_BC_ABI_VERSION
+ || value == GCJ_41_BC_ABI_VERSION);
}
// It makes the source cleaner if we simply always define this