Glibc uses these new symbol names to support IEEE-754 128-bit float support.
Details
- Reviewers
nemanjai jsji rjmccall - Group Reviewers
Restricted Project - Commits
- rG4f94c0261602: [Clang] Mutate bulitin names under IEEE128 on PPC64
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
clang/lib/CodeGen/CGBuiltin.cpp | ||
---|---|---|
100 | Why only these printf builtins? I think there are full list of similar libcalls in GLIBC_2.32 and later? | |
120 | How do we deal with the glibc version? Do we assume that user has glibc newer than GLIBC_2.32? | |
122 | Do we have to do it here? Can we just update the libcall names in RuntimeLibcalls.def or setLibcallName similar to others? |
clang/lib/CodeGen/CGBuiltin.cpp | ||
---|---|---|
100 | Yes, Glibc redirects all these functions depending on long double semantics, and GCC has corresponding builtins for almost all library functions (https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html). But currently clang doesn't have all of these builtins (for example, __builtin_scanf). It seems beyond this patch's scope to make the list complete. | |
120 | I notice not all libcall symbols are implemented in compiler-rt, which means we don't need to always expect all libcalls emitted are available in current libc? It's surprising that libc version are not checked in clang/driver/toolchain part. The only place checking libc version is in sanitizer. Maybe we can use that to emit warnings, like D112906. | |
122 | I think we cannot fill these calls in backend's runtime libcall list, because it contains supplementary routine names for legalizing IR instruction/intrinsics. Here the builtins are just converted into normal function calls in IR. |
LGTM. Please hold a few days to see whether there are inputs from other reviewers. Thanks.
clang/lib/CodeGen/CGBuiltin.cpp | ||
---|---|---|
100 | OK. Thanks. Can we add a TODO note. |
Why only these printf builtins? I think there are full list of similar libcalls in GLIBC_2.32 and later?