hvdijk wrote:

That would be nice, but that will take time, and I did wait months already 
before creating this PR. Leaving Clang in its current state until someone steps 
up to fix it, in my opinion, does a massive disservice to users.

If code is written to use `_BitInt`, and it correctly uses configure or CMake 
checks to try to detect compiler support, and fall back to some other 
implementation if `_BitInt` is unavailable, such code would, with Clang, use 
the non-working implementation. In which case the configure or CMake check 
would end up amended to "and if Clang, don't bother". From experience, such 
checks remain for far too long after the original problem is fixed; leaving 
Clang in its current state, I suspect, ensures that once Clang behaves 
correctly, still `_BitInt` will not be used.

I'm happy if someone is willing to step up to fix the implementation, but I am 
not able to do it, and I would really like to avoid Clang 18 being released in 
this broken state, if possible, and I see no way short of a revert to 
realistically achieve that.

https://github.com/llvm/llvm-project/pull/81175
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to