efriedma added a comment. Historically, the required functions for a "freestanding" C implementation were very restricted. Freestanding headers didn't export library functions, just constants and types.
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 . > 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. > 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. 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
