Apple clang compiler versioning schema?

Question

Some time ago, GCC >= 5 and Clang >= 4 compilers changed the semantics of their version numbers, so major version number will increase on any non-bugfix release.

Does Apple follow any versioning schema with clang compiler in terms of ABI compatibility or any other scope? I would like to know if apple-clang 9.0 is ABI compatible with 9.1 and so on.

Atelier

gist.github.com/yamaya/2924292 – Freezing

I'm not looking for the relationship between xcode and clang, but what does it mean the version of clang, the versioning schema they are following. – Atelier

Answer 1

Apple bumps their compiler version number with every Xcode release, so the appropriate place to look for ABI changes are the Xcode release notes. The newest ABI change I could find there was is Xcode 6:

The libc++ headers in Xcode 6 include a change to make std::pair have a trivial constructor. This fix is important for performance and compliance with the C++ standard, but it changes the ABI for C++ code using std::pair.

This implies that there were no ABI changes since 2014.

Edit: The mapping between clang and apple-clang seems to be (taken from here and added the last line myself by feature-testing):

5.1 -> 3.4
6.0 -> 3.5
7.0 -> 3.7
7.3 -> 3.8
8.0 -> 3.9
9.0 -> 4.0
9.1 -> 5.0

So I guess apple bumps the minor version of apple-clang whenever they integrate changes from mainline clang in between major Xcode releases.

But for the original question this does not matter: ABI compatibility of the language will not change until they say so, which is possible for the standard library (but rarely happens) and is almost unthinkable for the core language. For GCC, apple even guaranteed to not do the latter, but probably forgot to update the document when they switched to clang:

Because GCC 4.0 conforms to the Itanium C++ ABI, C++ objects are link-compatible with objects built by other OS X compilers that conform to this specification. Apple guarantees that future releases of GCC for OS X will also conform to the Itanium C++ ABI. This means that developers may safely ship dynamic shared libraries whose interfaces involve C++ classes, albeit with some caveats:

• Apple guarantees ABI stability only for core language features. It does not guarantee stability for library classes, including std::string, std::map, and std::ostream among others.

But as the gcc command links to apple-clang with any recent Xcode installation, this guarantee should hold for the latter as well.

Putscher

So, you mean that there is no correlation between clang ABI and it's versioning, right? – Atelier

yes, both for "official" clang and for apple llvm c++ compiler the versioning is time-based, and not ABI-based – Putscher

But they not always bump the version of clang when releasing xcode, so it has to be additional criteria? Between xcode 9.1 and xcode 9.2 clang kept to 9.0 # Xcode 9.1 (9B55) Apple LLVM version 9.0.0 (clang-900.0.38) # Xcode 9.2 (9C40b) Apple LLVM version 9.0.0 (clang-900.0.39.2) # Xcode 9.3 (9E145) Apple LLVM version 9.1.0 (clang-902.0.39.1) – Atelier

I have edited the answer, is this what you were looking for? – Putscher

I was expecting something not based on observing and guessing, but I assume no one has the answer except Apple, and probably the answer is: No, there is no correlation between versioning and ABI. – Atelier

It is as official as it gets: The last link give you the guarantee to not change the core language ABI for GCC and currently the gcc command in terminal links to apple-clang – Putscher

But it doesn't mention anything about the versioning. And also they say later: If you are designing a dynamic shared library for distribution, it is still your responsibility to ensure that you do not create binary compatibility problems. so the compatibility is not really kept, of course, if I write a "C" API it is ABI compatible, but it is not the same as GCC or CLANG guarantees, that can be translated to: "If the compiler doesn't bump the major version, your libraries are compatible no matter how you programmed them". It is a big difference. – Atelier

Just read on to the next sentence, they explain what they mean by your responsibility: For example, you should not introduce member variables or virtual methods to a base class. The warning you quote is therefore independent of core language ABI. – Putscher

Maybe you can post the source of the guarantees for GCC and clang. The links in your question do not contain them... – Putscher