Fragile ABI checks
- Dominant language
- LLVM
- Stars
- 1.5k
- Forks
- 854
- Avg merge
- 3d 17h
- Merged PRs (30d)
- 137
Description
I'm using a recent gcc distribution (gcc-12.2) with the default libstdc++, and `sycl/test/abi/layout_handler.cpp` fails for me on `intel/intel`
The ABI itself has not changed, but some parts of libstdc++ have had minor name changes to internal structures that are not part of an interface being tested.
It seems to me that tests that are string matching against libstdc++ internals are fragile, and this is not actually testing the user ABI of the given class that *we dpc++ developers control*.
This raises a few questions:
1. Do we count libstdc++'s ABI guarantees (hint: [they're not really guarantees](https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html)) transitively as our own?
2. If libstdc++ doesn't guarantee a stable ABI between gcc versions, should we only support building SYCL applications with specific gcc versions?
3. If not (2), then do we guarantee ABI stability for our part of the interface assuming the user builds with compatible libstdc++ versions?
4. How do we test either of the options presented above in a way that doesn't start testing internals?
I currently don't have good answers to any of the above questions, but think we could make the tests less fragile as a first step
Contributor guide
Assessment
This issue has not been assessed yet.