bcraig added a comment.

> 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?

Well, people want all sorts of things :)

(Gross generalizations coming) The compiler writer view of freestanding that 
I've heard in the past is that the compiler writer views freestanding as the 
necessary parts of the library needed to support the language.  This is mostly 
accurate when describing freestanding prior to C++23 and C23.  Most of that is 
either header-only, in libc++abi, or in compiler-rt.  This makes testing the 
compiler a bit easier, as you don't need a full stdlib.  That's not a design 
goal of freestanding post C/C++23 though.  It's fine for Clang to provide half 
of a stdlib for internal testing or integration with other C libraries, so long 
as the final toolchain has everything.

One challenge for some customers will be that they like to build with 
`-nodefaultlibs`, but that's not a deal breaker here, it just means that they 
would need to manually put their C library on the link line.  Alternatively, 
they could start passing other linker flags, like `-nostartfiles` instead, but 
that will be use case dependent.  These kinds of hoops have historically been 
needed because a customer may use a "stock" ARM Clang, but not want to use the 
libc that came with that toolchain, so the big linker flags would come out to 
give the user control.

I don't think that Clang-the-compiler needs to do anything to support the new 
C/C++ freestanding features.  The main caveat being that you still need to be 
able to ensure the provided memcpy gets used instead of a codegenned (possibly 
vectorized) memcpy, but I think -ffreestanding already forces the compiler to 
generate calls and not use in-compiler codegen.

> 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.

That would be much appreciated.  I can try to get my INCITS / ISO status 
squared away so that I can represent that issue at the appropriate meeting.


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

Reply via email to