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
Andrew Haley wrote:
Tom Tromey writes:
> >>>>> "Andrew" == Andrew Haley <aph@redhat.com> writes:
>
> Andrew> The idea is that rather than calling _Jv_InitClass for every static
> Andrew> field we call _Jv_ResolvePoolEntry instead. We also cache these
> Andrew> locally so that _Jv_ResolvePoolEntry is only called once.
>
> I think if we add a new function to the exported interface, then we
> must rev the BC ABI version that we claim to be generating. The
> reason for this is that the gcj with this patch will generate code
> which won't work with an earlier libgcj. So, I think we must increase
> the revision.
>
> (I suppose the counter argument is that such objects will simply fail
> to link.. ?)
The counter argument is that, of necessity, the ABI of gcc HEAD is
experimental; to bump the ABI # on every minor change is unnecessary.
In the case of a released gcc it's a different story.
Yes, we should not be changing the ABI version number with every minor
change, however, experimental versions should have a different version
number to released versions - ie we should bump the version number the
first time such a change is made on HEAD after a release. This will
avoid confusion when binaries made with HEAD are accidentally run on an
older release version.
How about something like this? Or would it be better to explicitly
define each different version somewhere?
Bryce
2005-05-03 Bryce McKinlay <mckinlay@redhat.com>
* decl.c (GCJ_CURRENT_BC_ABI_VERSION): Bump version ID.
2005-05-03 Bryce McKinlay <mckinlay@redhat.com>
* include/jvm.h (_Jv_CheckABIVersion): Accept past and present
BC-ABI version IDs.
Index: gcc/java/decl.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/java/decl.c,v
retrieving revision 1.219
diff -u -r1.219 decl.c
--- gcc/java/decl.c 29 Apr 2005 18:42:48 -0000 1.219
+++ gcc/java/decl.c 3 May 2005 23:18:50 -0000
@@ -64,12 +64,11 @@
/* Used when computing the ABI version. */
#define GCJ_BINARYCOMPAT_ADDITION 5
-/* 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 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;
Index: libjava/include/jvm.h
===================================================================
RCS file: /cvs/gcc/gcc/libjava/include/jvm.h,v
retrieving revision 1.84
diff -u -r1.84 jvm.h
--- libjava/include/jvm.h 29 Apr 2005 18:35:36 -0000 1.84
+++ libjava/include/jvm.h 3 May 2005 23:18:50 -0000
@@ -566,17 +566,15 @@
#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.
-#define GCJ_40_BC_ABI_VERSION (4 * 10000 + 0 * 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 backwards compatible with all known BC ABI
+ // versions.
+ || (value % 10 == GCJ_BINARYCOMPAT_ADDITION
+ && value <= GCJ_VERSION + GCJ_BINARYCOMPAT_ADDITION))
}
// It makes the source cleaner if we simply always define this