[PATCH] D144889: [C2x] Support in freestanding

aaron.ballman added a comment. In D144889#4158935 , @jyknight wrote: >> On the other hand, I think a not-insignificant number of users are >> interested in freestanding environments for one-off/fun/experimental >> projects where ease of access is more i

[PATCH] D144889: [C2x] Support in freestanding

jyknight added a comment. > On the other hand, I think a not-insignificant number of users are interested > in freestanding environments for one-off/fun/experimental projects where ease > of access is more important than performance characteristics -- think: users > who are playing around with

[PATCH] D144889: [C2x] Support in freestanding

bcraig added a comment. Let's talk about these use cases. > On the one hand, I think many users will want a libc that targets their > particular freestanding environment so that they get the best performance > characteristics (and other considerations) for their target. I think this fits kerne

[PATCH] D144889: [C2x] Support in freestanding

aaron.ballman added a comment. In D144889#4157257 , @jyknight wrote: > In D144889#4156974 , @rsmith wrote: > >> Likely because of GCC's perspective on this, the set of C headers provided >> by GCC, Clang, ICC, et

[PATCH] D144889: [C2x] Support in freestanding

jyknight added a comment. In D144889#4156974 , @rsmith wrote: > Likely because of GCC's perspective on this, the set of C headers provided by > GCC, Clang, ICC, etc. has included the complete list of freestanding headers > and more or less no others, wi

[PATCH] D144889: [C2x] Support in freestanding

rsmith added a comment. Do we know what GCC intends to do about this C change? Per their documentation , they intend for GCC to be / eventually become a complete freestanding implementation without need for a separate libc: > GCC aims towards

[PATCH] D144889: [C2x] Support in freestanding

efriedma added a comment. > perhaps because they did char buf[256] = {0} though Right, we need memcpy and memset to emit reasonable code for struct/array initialization and assignment. We don't provide any library that includes memcpy/memset/memmove because of a combination of legacy, and that

[PATCH] D144889: [C2x] Support in freestanding

bcraig added a comment. > 1. A normal operating system target with a "hosted" libc. > 2. A baremetal target with an "embedded" libc; basically a stripped down libc > which only includes stuff that doesn't require an operating system. What > exactly this includes varies; may include some form of

[PATCH] D144889: [C2x] Support in freestanding

efriedma added a comment. In 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

[PATCH] D144889: [C2x] Support in freestanding

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 (

[PATCH] D144889: [C2x] Support in freestanding

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 (

[PATCH] D144889: [C2x] Support in freestanding

aaron.ballman added a comment. In 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.

[PATCH] D144889: [C2x] Support in freestanding

bcraig added a comment. 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 requir

[PATCH] D144889: [C2x] Support in freestanding

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

[PATCH] D144889: [C2x] Support in freestanding

aaron.ballman added a comment. In D144889#4155686 , @efriedma wrote: > Providing this header doesn't do anything useful without an actual > implementation; all of these "__builtin" calls just lower to libc calls in > the general case. How do you plan t

[PATCH] D144889: [C2x] Support in freestanding

efriedma requested changes to this revision. efriedma added a comment. This revision now requires changes to proceed. Providing this header doesn't do anything useful without an actual implementation; all of these "__builtin" calls just lower to libc calls in the general case. How do you plan t

[PATCH] D144889: [C2x] Support in freestanding

aaron.ballman created this revision. aaron.ballman added reviewers: clang-language-wg, jyknight, efriedma, joerg. Herald added a project: All. aaron.ballman requested review of this revision. Herald added a project: clang. This implements most of the support for WG14 N2524 (https://www.open-std.o