[PATCH] D86993: Document Clang's expectations of the C standard library.

aaron.ballman added a comment. In D86993#4655487 , @rsmith wrote: > In D86993#4655474 , @RalfJung wrote: > >> With everything moving to github PRs, what are the next steps for this patch? > > I'm unlikely to have

[PATCH] D86993: Document Clang's expectations of the C standard library.

rsmith added a comment. In D86993#4655474 , @RalfJung wrote: > With everything moving to github PRs, what are the next steps for this patch? I'm unlikely to have cycles to work on this in the near future. If someone else wants to take over here, you

[PATCH] D86993: Document Clang's expectations of the C standard library.

RalfJung added a comment. With everything moving to github PRs, what are the next steps for this patch? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D86993/new/ https://reviews.llvm.org/D86993 ___

[PATCH] D86993: Document Clang's expectations of the C standard library.

aaron.ballman added a comment. In D86993#4584619 , @nikic wrote: > @aaron.ballman I wanted to check back whether the linked document is what you > had in mind, or whether some more/else would be needed. Sorry about the delayed review; this fell off my

[PATCH] D86993: Document Clang's expectations of the C standard library.

nikic added a comment. @aaron.ballman I wanted to check back whether the linked document is what you had in mind, or whether some more/else would be needed. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D86993/new/ https://reviews.llvm.org/D86993

[PATCH] D86993: Document Clang's expectations of the C standard library.

nikic added a comment. Sorry for the delay, this took more time than expected. I've created an initial draft here: https://docs.google.com/document/d/1guH_HgibKrX7t9JfKGfWX2UCPyZOTLsnRfR6UleD1F8/edit?usp=sharing While writing this I remembered another bit that is somewhat relevant here: Clang

[PATCH] D86993: Document Clang's expectations of the C standard library.

aaron.ballman added a comment. In D86993#4497851 , @xbolva00 wrote: > In D86993#4497744 , @aaron.ballman > wrote: > >> In D86993#4477744 , @RalfJung wrote: >> >>> It would

[PATCH] D86993: Document Clang's expectations of the C standard library.

xbolva00 added a comment. In D86993#4497744 , @aaron.ballman wrote: > In D86993#4477744 , @RalfJung wrote: > >> It would probably be worth including all string functions that take a length >> in such a DR. In

[PATCH] D86993: Document Clang's expectations of the C standard library.

aaron.ballman added a comment. In D86993#4477744 , @RalfJung wrote: > It would probably be worth including all string functions that take a length > in such a DR. In Rust we are currently puzzling over whether calling 0-length > `memcmp` on something

[PATCH] D86993: Document Clang's expectations of the C standard library.

RalfJung added a comment. It would probably be worth including all string functions that take a length in such a DR. In Rust we are currently puzzling over whether calling 0-length `memcmp` on something like `(char*)42` is okay or not. If not we'd have to introduce a pretty pointless branch.

[PATCH] D86993: Document Clang's expectations of the C standard library.

nikic added a comment. In D86993#4477080 , @aaron.ballman wrote: > In D86993#4474682 , @nikic wrote: > >>> I continue to think it's a mistake for us to document that Clang will not >>> work with a conforming C

[PATCH] D86993: Document Clang's expectations of the C standard library.

aaron.ballman added a comment. In D86993#4474682 , @nikic wrote: >> I continue to think it's a mistake for us to document that Clang will not >> work with a conforming C standard library implementation unless we're filing >> issues with WG14 to alert

[PATCH] D86993: Document Clang's expectations of the C standard library.

nikic added a comment. In D86993#4474392 , @rjmccall wrote: > In D86993#4474267 , @RalfJung wrote: > >> The first point is important for LLVM's own memcpy/memmove intrinsics, which >> are documented as NOPs on

[PATCH] D86993: Document Clang's expectations of the C standard library.

RalfJung added a comment. I was told that "glibc explicitly only marks memcpy arguments as nonnull for external use of headers (i.e. the nonnull assumptions are disabled when compiling the implementation)"... okay now re-reading this, that's a statement about glibc, not GCC. Anyway this is

[PATCH] D86993: Document Clang's expectations of the C standard library.

stephenpeckham added a comment. Is memmove() expected to perform a lot worse than memcpy()? Why not just use memmove() all the time. In some library implementations, memcpy() and memmove() are the same function. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION

[PATCH] D86993: Document Clang's expectations of the C standard library.

rjmccall added a comment. You can't just consider the declared function signatures; `memcpy`ing two non-empty objects with perfect overlap is a violation of `restrict`, and yet IIRC GCC is known to assume that that works in some places. (I can't duplicate that off-hand, though — GCC seems

[PATCH] D86993: Document Clang's expectations of the C standard library.

xbolva00 added a comment. In D86993#4474403 , @RalfJung wrote: > Yeah, agreed. Though I hear that GCC makes similar assumptions, so this > should count as something I think. (I don't have a source for this, so it > should probably be verified.) glibc's

[PATCH] D86993: Document Clang's expectations of the C standard library.

RalfJung added a comment. Yeah, agreed. Though I hear that GCC makes similar assumptions, so this should count as something I think. (I don't have a source for this, so it should probably be verified.) Anyway I don't think LLVM documenting its assumptions should be blocked on changing the C

[PATCH] D86993: Document Clang's expectations of the C standard library.

rjmccall added a comment. In D86993#4474267 , @RalfJung wrote: > The first point is important for LLVM's own memcpy/memmove intrinsics, which > are documented as NOPs on size 0 (and e.g. Rust relies on that). Right, I understand that these assumptions

[PATCH] D86993: Document Clang's expectations of the C standard library.

RalfJung added a comment. The first point is important for LLVM's own memcpy/memmove intrinsics, which are documented as NOPs on size 0 (and e.g. Rust relies on that). `memset` should be added to that list. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION

[PATCH] D86993: Document Clang's expectations of the C standard library.

rjmccall added a comment. I agree with Aaron that it would be better to change the C standard if we can. I don't know how important the first bullet is; IIRC it enables some useful middle-end transformation. I know the second is useful in the frontend so that we don't have to do explicit

[PATCH] D86993: Document Clang's expectations of the C standard library.

aaron.ballman added a comment. In D86993#4471912 , @RalfJung wrote: > What is the status of this patch? It has not been committed as far as I can > tell. Correct, it's not been committed yet. we're still discussing (though that's obviously stalled out

[PATCH] D86993: Document Clang's expectations of the C standard library.

RalfJung added a comment. Herald added a subscriber: StephenFan. Herald added a project: All. What is the status of this patch? It has not been committed as far as I can tell. I was looking into this coming from Rust, where we do worry a bit about LLVM calling `memcpy`, `memmove` or `memset`

[PATCH] D86993: Document Clang's expectations of the C standard library.

aaron.ballman added inline comments. Comment at: clang/docs/Toolchain.rst:289 + +C standard library implementations that do not guarantee these properties are +incompatible with Clang and LLVM (and with several other major compilers). While I think it's good

[PATCH] D86993: Document Clang's expectations of the C standard library.

rjmccall added a subscriber: t.p.northover. rjmccall added a comment. @t.p.northover says it's complicated. `memcpy`, `memmove`, `memset`, and `bzero` are (I think) the only ones that LLVM will potentially synthesize from nothing and therefore need to be present even in freestanding builds;

[PATCH] D86993: Document Clang's expectations of the C standard library.

rsmith added a comment. In D86993#2251198 , @rjmccall wrote: > Wording looks good. Should we alsso document our assumptions about what > functions exist in the standard library — the functions that we'll always use > even in freestanding builds?

[PATCH] D86993: Document Clang's expectations of the C standard library.

rjmccall added a comment. Wording looks good. Should we alsso document our assumptions about what functions exist in the standard library — the functions that we'll always use even in freestanding builds? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION

[PATCH] D86993: Document Clang's expectations of the C standard library.

rsmith updated this revision to Diff 289329. rsmith added a comment. Add missing word. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D86993/new/ https://reviews.llvm.org/D86993 Files: clang/docs/Toolchain.rst Index: clang/docs/Toolchain.rst

[PATCH] D86993: Document Clang's expectations of the C standard library.

rsmith created this revision. rsmith added reviewers: fhahn, rjmccall. Herald added a project: clang. Herald added a subscriber: cfe-commits. rsmith requested review of this revision. As suggested in https://reviews.llvm.org/D86815 Repository: rG LLVM Github Monorepo