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

[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

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D158169: [X86] Fix i128 argument passing under SysV ABI

[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 
)? Does that still work after this 
patch?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D158169/new/

https://reviews.llvm.org/D158169

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

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


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D86993/new/

https://reviews.llvm.org/D86993

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[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 outside my expertise. I will try to add Nikita here who said 
"GCC also requires passing equal pointer to memcpy to be legal".


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D86993/new/

https://reviews.llvm.org/D86993

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[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 standard. Maybe LLVM should have blocked *making* those 
assumptions on changing the standard, but that ship has sailed long ago...
(I have less of an opinion about clang since I am not involved there.)

> I think it makes sense to document this both from the Clang perspective and 
> from the LLVM perspective, as they're somewhat different.

What would be the right place in LLVM to document this?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D86993/new/

https://reviews.llvm.org/D86993

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[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
  https://reviews.llvm.org/D86993/new/

https://reviews.llvm.org/D86993

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

[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` in ways that are not allowed by the C 
standard. This here would at least give us something to point to, though it 
doesn't answer the question "which C standard libraries have officially 
committed to guaranteeing these properties". Since this affects all compilers 
using LLVM, not just Clang, should this be put somewhere in the LLVM docs?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D86993/new/

https://reviews.llvm.org/D86993

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits