[PATCH] D91531: [RFC][OpenCL] Provide mechanisms for defining extension macros

Anastasia added a comment. In D91531#2418237 , @mantognini wrote: > When reading the documentation [1] for -cl-ext (which I've never used so > far), I've noticed nothing is said about non-standard configurations (such as > disabling cl_khr_depth_images w

[PATCH] D91531: [RFC][OpenCL] Provide mechanisms for defining extension macros

mantognini added a comment. When reading the documentation [1] for -cl-ext (which I've never used so far), I've noticed nothing is said about non-standard configurations (such as disabling cl_khr_depth_images with CL2.0). Quickly testing this shows that options can be specified to produce non-s

[PATCH] D91531: [RFC][OpenCL] Provide mechanisms for defining extension macros

Anastasia added a comment. In D91531#2412532 , @azabaznov wrote: >> So if I understand it well you are suggesting to perform a check for every >> parsed macro definition that would identify whether the macro has a name >> matching what is provided in -cl

[PATCH] D91531: [RFC][OpenCL] Provide mechanisms for defining extension macros

azabaznov added a comment. > So if I understand it well you are suggesting to perform a check for every > parsed macro definition that would identify whether the macro has a name > matching what is provided in -cl-ext=? Then if the name matches it would > check whether the macro should be defin

[PATCH] D91531: [RFC][OpenCL] Provide mechanisms for defining extension macros

Anastasia added a comment. In D91531#2411725 , @azabaznov wrote: >> Perhaps if you give me an example it would help to understand > > I was meant that this can potentially be used to undefine macros inside clang > directly. In this case there will no need

[PATCH] D91531: [RFC][OpenCL] Provide mechanisms for defining extension macros

azabaznov added a comment. > Perhaps if you give me an example it would help to understand I was meant that this can potentially be used to undefine macros inside clang directly. In this case there will no need to add a lot of conditional preprocessor directives in the header, also the existing

[PATCH] D91531: [RFC][OpenCL] Provide mechanisms for defining extension macros

Anastasia added a comment. In D91531#2406390 , @azabaznov wrote: > Yes, in general this approach looks good to me conceptually. I have two > suggestions: > > 1. As we discussed, the term //core functionality// should be revisited here. > There's no clear

[PATCH] D91531: [RFC][OpenCL] Provide mechanisms for defining extension macros

azabaznov added a comment. Yes, in general this approach looks good to me conceptually. I have two suggestions: 1. As we discussed, the term //core functionality// should be revisited here. There's no clear meaning about that in the spec and I think interpreting it as //supported by default//

[PATCH] D91531: [RFC][OpenCL] Provide mechanisms for defining extension macros

Anastasia updated this revision to Diff 305721. Anastasia added a comment. - Added full diffs. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D91531/new/ https://reviews.llvm.org/D91531 Files: clang/include/clang/Basic/OpenCLExtensions.def clang/include/clang/Basic/TargetInfo.h cla