ABI compatibility between 19.0 (2019) and 19.1 (2020)

[Konstantin_I_]

hello,

disclaimer: I am working on Intel C++ Compiler support for Conan package manager. for us and our users, it's important to know when packages are fully ABI compatible, and when is it safe to mix objects/libraries produced by different versions of the compiler, in order to avoid run-time and compile-time compatibility issues.

the first question: did Intel C++ Compiler just change the versioning scheme? it seems like the new "major" release 2020 has version number 19.1, but not 20.0, which might be a bit confusing, as before we had major version number bump for each year (e.g. 2018 - 18.0, 2019 - 19.0, etc).

the second question: can we assume ABI compatibility between 19.0 (2019) and 19.1 (2020)? in other words, if we compile some C++ library by 19.1, can we safely link this library into application compiled by 19.0? (assuming the library may use C++ interfaces and C++ API, e.g. pass vectors, strings, etc. on library boundaries. also assuming compiler flags are the same - C++ standard, etc).

so far, I have found few things in the official release notes:

Features/APi changes

More algorithms support parallel and vector execution policies: find_first_of, is_heap, is_heap_until, replace, replace_if.

More algorithms support vector execution policies: remove, remove_if.

More algorithms support parallel execution policies: partial_sort.

and:

The Intel® C++ Compiler 19.1 supports the following features under the /Qstd=c++20 (Windows*) or -std=c++20 (Linux*/OS X*) options:

std::is_constant_evaluated and __builtin_is_constant_evaluated

thus, I'd assume if library is using Parallel STL it might be unsafe to mix 19.0 and 19.1.

I've also have compared some Intel compiler libraries and found several differences in public symbols provided:

110a111
> __intel_avx_memmove
129a131
> __intel_new_feature_proc_init_n
296a299
> _intel_fast_memmove.V
358d360
< get_feature_name
361d362
< isa_init_once

110a111,113
> _ZN3tbb8internal13numa_topology11nodes_countEv
> _ZN3tbb8internal13numa_topology19default_concurrencyEi
> _ZN3tbb8internal13numa_topology4fillEPi
164a168
> _ZN3tbb8internal24itt_metadata_ptr_add_v11ENS0_15itt_domain_enumEPvyNS0_12string_indexES2_

which also might cause some incompatibilities if the library is using such symbols.

[AbhishekD_Intel]

Hi Konstantin,

We really like your findings with ICC 19.0 and 19.1 compiler. Here are the solutions to your questions.

1. We can't say that there is a change in versioning scheme, but the 2020 release of PSXE (PSXE-2020) has ICC 19.1 compiler.
2. There are some new features that are added into ICC 19.1 (shown by you) which are not there in ICC 19.0 compiler. So the new feature will not be compatible with the old versions, whereas the .o files made with the previous release will continue to work throughout the next major version and the same applies to .so files. So the libs which are built over 19.0 would continue to work with 19.1. But the .o and .so made by 19.1 may or may not work with older versions due to possible changes in run-time libraries. Even if you successfully compile your application using these run-time libraries there may be a chance that your resulting program will become unstable.

The product with which you are working must be demanding for a stable program. So I will suggest you to first check the stability of your program with all the libraries and API you are using in your program because they might cause incompatibilities.

You can also use -fabi-version=<val> flag with ICC compiler which will help you to select specific ABI implementations.

I hope your problem gets resolved, and I appreciate your findings because it is very important in order to make a stable and robust program.

Stay Healthy Stay Safe!

Warm Regards,

Abhishek

[GouthamK_Intel]

Hi,

We hope the resolution provided helped you.

In case of any further queries please feel free to raise a new thread.

Thanks

Goutham