Hopefully, -fno-builtin-memccpy will work now. Required for https://reviews.llvm.org/D67986.
Details
Diff Detail
- Repository
- rC Clang
Event Timeline
include/clang/Basic/Builtins.def | ||
---|---|---|
903 | Well, technically, C 20. |
Test cases?
include/clang/Basic/Builtins.def | ||
---|---|---|
483 | GCC doesn't seem to have __builtin_memccpy? https://godbolt.org/z/jbthQ3 |
It is not very obvious for me what kind of test should be done here. I would be grateful if you could show me an example in tree.
Exactly for -fno-builtin-memccpy case?
include/clang/Basic/Builtins.def | ||
---|---|---|
483 | Ok, I will drop it. |
I was thinking of something in CodeGen, like CodeGen/builtin-memfns.c
Exactly for -fno-builtin-memccpy case?
That would be another good test case.
include/clang/Basic/Builtins.def | ||
---|---|---|
483 | If you drop it, won't that lose the builtin? I was mostly thinking it's in the wrong part of the list of builtins. |
include/clang/Basic/Builtins.def | ||
---|---|---|
483 | Rebuilding LLVM + Clang in progress so I just checked it in godbolt with "strtol" - defined only as LIBBUILTIN, no __builtin version. nobuiltin attribute is correctly handled, so I think it will work. |
include/clang/Basic/Builtins.def | ||
---|---|---|
483 | Ah, I see the issue better now. The description for this review was very terse and it wasn't immediately clear what problem you were trying to solve. Yeah, I think this declaration can go away. | |
984 | Isn't memccpy supported by Visual Studio? What should happen there? |
include/clang/Basic/Builtins.def | ||
---|---|---|
984 | ”This POSIX function is deprecated. Use the ISO C++ conformant _memccpy instead.“ |
include/clang/Basic/Builtins.def | ||
---|---|---|
984 | Thanks for verifying it's still supported (deprecated != unsupported). We do support other Microsoft builtins, so should this one be added? |
include/clang/Basic/Builtins.def | ||
---|---|---|
984 | Ok, I will add it. One last question, should I somehow represent that memccpy is in C 20 (if so, how) ? |
include/clang/Basic/Builtins.def | ||
---|---|---|
984 | You should probably start a new section for C2x library functions and add memccpy, strdup, and strndup to it. Also, just to double-check: we don't encode restrict into builtin signatures, do we? (Should we?) |
include/clang/Basic/Builtins.def | ||
---|---|---|
483 | Yeah, I am sorry, more context why this is needed: |
include/clang/Basic/Builtins.def | ||
---|---|---|
984 |
Okay, thanks - probably not needed for now (should be separate patch to handle new functions in C 2X anyway; maybe more functions to be added?)
Maybe catch very simple overlap issues? I dont think this is worth it (we have sanitizers). LLVM annotates libc functions with noalias anyway. |
include/clang/Basic/Builtins.def | ||
---|---|---|
483 | Thank you for the extra context! | |
984 |
Yeah, can totally be done in a separate patch.
Sanitizers don't run everywhere, but more importantly, I was wondering about the possible optimization opportunities by noting which arguments cannot overlap with one another (perhaps noalias covers that; I'm less familiar with the llvm side of things). However, I looked at the file and see we don't have any encodings for it, so nothing to be done here. |
include/clang/Basic/Builtins.def | ||
---|---|---|
984 |
This is implemented in LLVM. For example: https://godbolt.org/z/E8x2Ev (see line 10).
GCC emits a lot of warnings from middle-end. While I dont like some implementations which are part of regular pass, but extra warning pass just to check specific thing is nice idea I think (that pass is enabled only with -Wxxxx flag). |
Hm,
Maybe we have a bug in LLVM's TLI? TLI says Win32 has no memccpy.
https://llvm.org/doxygen/TargetLibraryInfo_8cpp_source.html line 333
cc @RKSimon since he knows windows-related things more.
Current solution does not work
/home/xbolva00/LLVM/llvm/tools/clang/include/clang/Basic/Builtins.h:50:34: error: redefinition of ‘BImemccpy’
#define BUILTIN(ID, TYPE, ATTRS) BI##ID,
^
/home/xbolva00/LLVM/llvm/tools/clang/include/clang/Basic/Builtins.h:50:34: note: in definition of macro ‘BUILTIN’
#define BUILTIN(ID, TYPE, ATTRS) BI##ID,
@aaron.ballman, maybe you can help me how to represent that memccpy exists for GNU and MS?
We may not have the machinery needed for doing this yet, in which case, I think it's fine to ignore the MS builtin.
LGTM aside from a minor testing nit.
clang/test/CodeGen/memccpy-libcall.c | ||
---|---|---|
13 ↗ | (On Diff #226571) | Please add the newline to the end of the file. |
GCC doesn't seem to have __builtin_memccpy? https://godbolt.org/z/jbthQ3