Cons-Cat
Backporting to work with a released version of GCC or Clang?
Hello @Cons-Cat,
Thank you for this interesting project. May I know if (in your view) it will be useful for me to try to "backport" the current version to an officially released version of GCC or Clang, in contrast to a bleeding-edge development version?
I am currently forking from an older commit (65d1603552e9d6aa9745a019d0b77a4041bf94de), since it works with my GCC 14.2 installation. But perhaps there is something I am missing.
Thank you very much!
There are two main reasons that libCat is currently building for Clang 20 (GCC 15 currently results in an internal compiler error, and I'm considering dropping support for it entirely to make several Clang features easier to use).
The first is that GCC 15 has better feaure-parity with Clang type trait intrinsics, which I used in the commit immediately after 65d1603 (3984312). The reason I use these is because they compile faster, although it wouldn't be difficult to conditionally support them with __has_builtin as I still do with some other intrinsics such as __is_invocable. I will note that GCC 15 currently fails to build recent libCat due to an ICE (internal compiler error). Currently I have no idea why, but I could run cvise on libCat to find out why. There are also other recently supported features ported from Clang like [[clang::must_tail]], __builtin_operator_new, [[clang::counted_by]], etc. which I might use for optimization and analysis purposes in the future. I think those three examples are only available in GCC 15, but I doubt they would block a backporting effort. For what it's worth, GCC 15 is nearing its release date, which will probably be next January.
The other reason I used GCC 15 is that it supports delete reasons from C++26. I love this feature, but it could be conditionally removed by an #ifdef without changing the meaning of a program, only the diagnostics. There are other C++26 features I might use soon, such as constexpr placement-new which would let me remove my implementation of std::construct_at, and pack-indexing which is more generally useful than __type_pack_element. I also really want to use the upcoming "structured-bindings can introduce a pack" right here, which will allow me to pass in multiple arguments to a child thread. That would be difficult to back-port, because the current template techniques for writing this feature in standard library implementations are very complicated.
In the future, I also would like to use _Generic in some places rather than cat::conditional, because I have nested conditional specializations that take a long time for compilers to evaluate compared to _Generic, which is only supported in C++ by Clang and likely will never be supported in C++ by GCC. _Decimal and _Complex literals have a similar problem, as does any use of _BitInt, which could allow me to optimize build times by replacing templates in some places. GCC also forbids using type-trait intrinsics in function signatures, which is permitted by Clang and could remove even more template specializations.
That said, I do realize this is a big burden on most users. I've looked into writing and providing an asdf plugin to make acquiring a compatible toolchain easier, and I'm totally open to suggestions on other ways to make libCat less painful to build until it eventually stabilizes on a released compiler version.
