What does the ABIVersion mean?

[iains]

It seems that this value might have different interpretations depending on the auxiliary bits.

So ..
gcc/java/decl.cc parse_version() which makes a distinction between cases with flag_indirect_dispatch and not.

and
libjava/java/lang/natClassLoader.cc _Jv_CheckABIVersion()

In the short term the representation of GCJ_CXX_ABI_VERSION (-findirect-dispatch is off) needs to be represented in 20bits (unless we elect to allocate more of the version bits to the number) which means it cannot be 100000 * __GNUC__

• for proof of principle I modified my local code to __GNUC__ * 65536 .. treating the version contract as C++-specific in that case but meaning something completely different when -findirect-dispatch is on.

NOTE that the current value for -findirect-dispatch is 4 * 100000 + ... which suggests that it was not updated for GCC 5 or 6. which makes it seem like this contract might not need to depend on the GCC version.

Once we understand the meaning and what other bits in the word are reserved for, we can decide how to represent the GCC version (C++) and/or other things (-findirect-dispatch).

[Zopolis4]

I did some blaming, came across 97fceb9 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70839) and a564d35.

Not sure yet, but maybe just 10000 * __GNUC__ would work?

[Zopolis4]

I also found 0e8d41a. Now i'm pretty confident that 10000 * __GNUC__ would work, although I'm unable to test this rn.

[iains]

I also found 0e8d41a. Now i'm pretty confident that 10000 * __GNUC__ would work, although I'm unable to test this rn.

I chose to use 65536 * __GNUC__ on the basis that would allow one byte for each of major, minor, patch should that become necessary (of course, we can do any arithmetic we like - but trying to cater for future needs without using up too much resource).

edit:
and natClassLoader.cc also needs to extend its version check to 24bits:
unsigned long version = value & 0xfffffUL;

These changes are speculative tho, pending decisions on the overall way forward (and this stuff is probably not terribly important c.f. the other blockers to the VM startup)

ISTM that the existing values can remain as "special" and related to some potential backwards compatibility with gcc 4.x ... I do not know if there is any merit in such backwards compatibility after a long gap in support .. we might end up deleting all that and just starting again (conjecture, no supporting data yet).