vikramRH wrote: > I looked at the OpenCL spec for C standard library support and was surprised > that 1) it's only talking about C99 so it's unclear what happens for C11 > (clause 6 says "This document describes the modifications and restrictions to > C99 and C11 in OpenCL C" but 6.11 only talks about C99 headers and leaves > `iso646.h`, `math.h`, `stdbool.h`, `stddef.h`, (all in C99) as well as > `stdalign.h`, `stdatomic.h`, `stdnoreturn.h`, `threads.h`, and `uchar.h` > available?), and 2) OpenCL's `printf` is not really the same function as C's > `printf` > (https://registry.khronos.org/OpenCL/specs/3.0-unified/html/OpenCL_C.html#differences-between-opencl-c-and-c99-printf). > > #1 is probably more of an oversight than anything, at least with the C11 > headers. So maybe this isn't a super slippery slope, but maybe C23 will > change that (I can imagine `stdbit.h` being of use in OpenCL for bit-bashing > operations). However, the fact that the builtin isn't really `printf` but is > `printf`-like makes me think we should make it a separate builtin to avoid > surprises (we do diagnostics based on builtin IDs and we have special > checking logic that we perhaps should be exempting in some cases).
Understood. Then I propose the following. 1. Currently Builtin TableGen does not seem to support specifying lang address spaces in function prototypes. this needs to be implemented first if not already in development. 2. We could have two new macro variants probably named "OCL_BUILTIN" and "OCL_LIB_BUILTIN" which will take the ID's of the form "BI_OCL##<builtin_name>". we would also need corresponding TableGen classes (probably named similar to the macros) which can expose such overloaded prototypes when required. How does this sound ? https://github.com/llvm/llvm-project/pull/86801 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
