aaron.ballman added a comment. In D144889#4156068 <https://reviews.llvm.org/D144889#4156068>, @efriedma wrote:
> Historically, the required functions for a "freestanding" C implementation > were very restricted. Freestanding headers didn't export library functions, > just constants and types. <nods> > As a practical matter, we actually do need a few functions to support code > generation for C even if they don't include any standard library headers. We > expect "freestanding" users to provide the three functions memcpy, memmove, > and memset. Other misc. functions like large integer operations and floating > point are provided by compiler-rt.builtins (which is ABI-compatible with > libgcc). > > Note that we can't easily expand the API surface of compiler-rt.builtins; see > https://discourse.llvm.org/t/proposal-split-built-ins-from-the-rest-of-compiler-rt/67978 > . Oof. >> was that the first one is lowered to a potential library call while the >> second one is is lowered to a backend implementation that performs the work > > The difference is really that the __builtin_* functions are recognized as > builtins even if the the user is using -fno-builtin/-ffreestanding. It > doesn't mean we actually have dedicated codegen support. Ah, that's good to know. Thanks! >> We do not currently have builtins for memccpy, memset_explicit, or strtok > > I'm not sure it makes sense to provide a "freestanding" strtok; it requires > global state. I'm happy to file a CD2 comment to this effect. In D144889#4156120 <https://reviews.llvm.org/D144889#4156120>, @bcraig wrote: > A freestanding implementation doesn't necessarily mean that everything is > header-only. It's fine to require linking against a (freestanding) C runtime > library. All header-only is fine too though, if you want to make that work. > > Architecturally, I don't feel it is required that Clang be the location of > all the freestanding headers for C. I think that's fine for the C library in > the final toolchain to own those headers. I'm not super familiar with what > interface contracts you have between the clang-provided C headers and the > C-library provided C headers though. Okay, so this is potentially ignorance on my part. I was under the impression that folks using freestanding mode did not want any library to be linked in. Are there freestanding libc implementations out there that the user would link in instead that we defer to (same as we defer hosted C standard library interfaces to the CRT)? Basically, do we need to do nothing in Clang to support N2524? >> I'm not sure it makes sense to provide a "freestanding" strtok; it requires >> global state. > > I agree with this, but the C committee felt otherwise. C++26 freestanding is > most likely including strtok too, to stay consistent with C (the freestanding > C library paper is through LWG and awaiting a C++26 plenary vote). It > shouldn't be hard to implement in an OS-independent way, but it will be a low > quality implementation with cross-thread races. FWIW, WG14 is having a second round of CD ballot comments. If you'd like, I'm happy to file a comment asking to remove `strtok` from the required set for freestanding conformance. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D144889/new/ https://reviews.llvm.org/D144889 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
