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

2023-10-28 Thread Ralf via Phabricator via cfe-commits
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] D158169: [X86] Fix i128 argument passing under SysV ABI

2023-09-13 Thread Ralf via Phabricator via cfe-commits
RalfJung added a comment. > I think the CCIfSplit means it was larger than i64 to start. What about the case where R9 would take the *second* half of a split i128 (i.e., the value gets split across R8 and R9

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

2023-07-06 Thread Ralf via Phabricator via cfe-commits
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.

2023-07-05 Thread Ralf via Phabricator via cfe-commits
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.

2023-07-05 Thread Ralf via Phabricator via cfe-commits
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.

2023-07-05 Thread Ralf via Phabricator via cfe-commits
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.

2023-07-04 Thread Ralf via Phabricator via cfe-commits
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`