AaronBallman wrote: > > `unreachable` is morally similar to `offsetof` in that it's a macro > > interface where the implementation can give better results by expanding to > > a builtin than a library is likely to be able to give via a naive > > implementation, but the interfaces _can_ be provided by a CRT. > > FWIW I don't think they are morally similar. `unreachable` could be > implemented in very different ways. Consider a libc which tries to terminate > on UB instead of letting the compiler optimize things away (e.g. a debug > mode). Then the Clang implementation is not at all what the libc would do.
I think we're saying the same thing but in different ways. I'm saying that the compiler implementation is generally what's positioned best in terms of what the optimizer can work with but the library implementation can be positioned to have a conforming implementation with different QoI properties. There's benefits to allowing *either* approach; the compiler can provide a high-quality implementation so that C standard library maintainers don't have to do anything but the compiler's headers should not prevent a C standard library from providing additional/different functionality. > That's just my immediate reaction to this. It's pretty naive but at this > specific point I believe we should basically not provide any Clang builtin > headers except the ones that clearly provide compiler-related stuff (e.g. > <stdarg.h> or tmmintrin.h & friends). I'm eager to hear other people's takes > on this. There's two angles to this. We provide something already today and we don't want to break code, so whatever we provide tomorrow needs to have a good enough user experience that code either still works, or users have an easy way to react to the changes. So reducing the set of interfaces we provide is risky, though I would argue that the C23 offerings are the easiest for us to change because I'm unaware of any fully conforming C standard library for C23 yet. The other angle is where we want to be in an ideal situation. I do not think think "because of GCC compatibility, let's do what glibc does" is the correct default ideal situation for us to look at -- if we're going to make structural changes and document a policy, I would love for us to gather feedback from glibc, MSVC CRT, musl, ulibc, llvm-libc, bionic, and any other implementations (including STL implementations) we can find contacts for so we can intentionally support a wide set of C standard libraries from Clang without introducing significant burdens for C++ standard library maintainers. For example, we have problems like "who provides what for freestanding", but we also have serious issues with "who defines what" for predefined macros, because some of them (`__STDC_IEC_559__` and others) require a handshake between both parts of the implementation. So I think I see a short-term and a long-term project here. Long-term, we should find a way to migrate our existing headers to a more intentional approach (whatever that may be). Short-term, we need to do something for `unreachable` in `stddef.h` and I think there's two initial tasks: 1) can we find evidence that we still need the `__need` machinery or can that be removed entirely and simplify the interface in Clang? 2) The C++ standard isn't rebased on top of C23 yet, but WG21 needs to figure out what to do about https://eel.is/c++draft/cstddef.syn#1; it would be unintuitive for `cstddef` to not expose one of C interfaces, but it would be a problem for `cstddef` to provide a macro that then whacks the function declaration in `utility`. I can see WG21 solving this either by removing `unreachable` from `cstddef` or by requiring `utility` to guard against the macro via implementation magic (personally, I think `utility` should guard against it because of users including `stddef.h` directly) and it would be nice to know which direction the committee is leaning before we get too far into a solution. WDYT? Also, I'd love to hear from some llvm-libc folks. @jhuber6 @lntue (feel free to tag others) https://github.com/llvm/llvm-project/pull/86748 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
