[PATCH] D78777: [AST] Use PrintingPolicy for format string diagnosis

Anastasia accepted this revision. Anastasia added a comment. LGTM! Thanks! Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D78777/new/ https://reviews.llvm.org/D78777 ___ cfe-commits mailing list

[PATCH] D77923: OpenCL: Fix some missing predefined macros

Anastasia added a comment. Herald added a project: LLVM. Herald added a subscriber: llvm-commits. The current solution seems very specific and doesn't provide generic uniform mechanisms for the targets. Would something based on a triple component not work? CHANGES SINCE LAST ACTION

[PATCH] D78979: OpenCL: Include builtin header by default

Anastasia added a subscriber: svenvh. Anastasia added a comment. > I'm somewhat confused by the way this is supposed to work, or why a > separate option exists for OpenCL. The other language flags seem to be > implemented in the driver, not cc1 like OpenCL. I'm not sure this is > the right set

[PATCH] D77923: OpenCL: Fix some missing predefined macros

Anastasia added a comment. As for OpenCL C spec we should ideally add `__OPENCL_VERSION__` but I feel it should be taken from architecture or OS type... I think there were other cases where we needed something like an OpenCL runtime version in the triple too but I can't remember this now. I

[PATCH] D60193: [OpenCL] Added addrspace_cast operator

This revision was automatically updated to reflect the committed changes. Closed by commit rGa6a237f2046a: [OpenCL] Added addrspace_cast operator in C++ mode. (authored by Anastasia). Herald added a project: clang. Changed prior to commit: https://reviews.llvm.org/D60193?vs=263085=264581#toc

[PATCH] D60193: [OpenCL] Added addrspace_cast operator

Anastasia updated this revision to Diff 262479. Anastasia added a subscriber: jeroen.dobbelaere. Anastasia added a comment. Herald added subscribers: martong, arphaman. Sorry for long latency. I have rebased the patch to the current master and addressed the comments from @mantognini too.

[PATCH] D60193: [OpenCL] Added addrspace_cast operator

Anastasia added a comment. In D60193#1549806 , @mantognini wrote: > When compiling this I get the following warning: > > clang/lib/StaticAnalyzer/Core/ExprEngine.cpp:1213:10: warning: enumeration > value 'CXXAddrspaceCastExprClass' not handled in

[PATCH] D60193: [OpenCL] Added addrspace_cast operator

Anastasia marked 4 inline comments as done. Anastasia added inline comments. Comment at: lib/Sema/SemaCast.cpp:279 + case tok::kw_addrspace_cast: +if (!TypeDependent) { + Op.CheckAddrspaceCast(); mantognini wrote: > Still learning here, so could

[PATCH] D60193: [OpenCL] Added addrspace_cast operator

Anastasia updated this revision to Diff 263085. Anastasia added a comment. - Improved behavior by allowing casting between equivalent types. - Improved formatting. - Improved tests. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D60193/new/ https://reviews.llvm.org/D60193 Files:

[PATCH] D60193: [OpenCL] Added addrspace_cast operator

Anastasia marked 3 inline comments as done. Anastasia added inline comments. Comment at: clang/test/SemaOpenCLCXX/addrspace_cast.cl:19-24 +template +void test_temp(__global int *par) { + T *var1 = addrspace_cast(par); + __private T *var2 = addrspace_cast<__private T *>(par);

[PATCH] D79903: FastMathFlags.allowContract should be init from FPFeatures.allowFPContractAcrossStatement

Anastasia added inline comments. Comment at: clang/lib/Frontend/CompilerInvocation.cpp:2943 + if (Opts.FastRelaxedMath) +Opts.setDefaultFPContractMode(LangOptions::FPM_Fast); Opts.HexagonQdsp6Compat = Args.hasArg(OPT_mqdsp6_compat); mibintc wrote: >

[PATCH] D80317: [SYCL] Prohibit arithmetic operations for incompatible pointers

Anastasia added subscribers: jeroen.dobbelaere, rjmccall. Anastasia added inline comments. Comment at: clang/lib/Sema/SemaExpr.cpp:10090 // if both are pointers check if operation is valid wrt address spaces - if (S.getLangOpts().OpenCL && isLHSPointer && isRHSPointer) { +

[PATCH] D80416: [RFC][OpenCL] Set fp contract flag on -cl-mad-enable

Anastasia marked an inline comment as done. Anastasia added inline comments. Comment at: clang/test/CodeGenOpenCL/relaxed-fpmath.cl:21 +float fused_mad(float a, float b, float c) { + // NORMAL: @llvm.fmuladd.f32 + // FAST: fmul fast float I don't find this

[PATCH] D80416: [RFC][OpenCL] Set fp contract flag on -cl-mad-enable

Anastasia created this revision. Anastasia added reviewers: rjmccall, arsenm. Herald added subscribers: ebevhan, yaxunl, wdng. Anastasia marked an inline comment as done. Anastasia added inline comments. Anastasia retitled this revision from "[RCF][OpenCL] Set fp contract flag on -cl-mad-enable"

[PATCH] D80416: [RFC][OpenCL] Set fp contract flag on -cl-mad-enable

Anastasia added a comment. In D80416#2050250 , @arsenm wrote: > The langref wording makes me think this isn't quite right. This depends on > your definition of floating point contraction. I've always assumed it meant > allow FMA, potentially increasing

[PATCH] D80416: [RFC][OpenCL] Set fp contract flag on -cl-mad-enable

Anastasia marked an inline comment as done. Anastasia added inline comments. Comment at: clang/test/CodeGenOpenCL/relaxed-fpmath.cl:21 +float fused_mad(float a, float b, float c) { + // NORMAL: @llvm.fmuladd.f32 + // FAST: fmul fast float Anastasia wrote: >

[PATCH] D80416: [RFC][OpenCL] Set fp contract flag on -cl-mad-enable

Anastasia marked an inline comment as done. Anastasia added inline comments. Comment at: clang/test/CodeGenOpenCL/relaxed-fpmath.cl:21 +float fused_mad(float a, float b, float c) { + // NORMAL: @llvm.fmuladd.f32 + // FAST: fmul fast float Anastasia wrote: > I

[PATCH] D80440: [OpenCL] Prevent fused mul and add by default

Anastasia created this revision. Anastasia added reviewers: rjmccall, arsenm. Herald added subscribers: ebevhan, yaxunl, wdng. Currently, clang will generate fused operation `fmuladd` for expressions like `a*b+c`. However, I can't find anything in the spec that explains this behavior. But clang

[PATCH] D80416: [RFC][OpenCL] Set fp contract flag on -cl-mad-enable

Anastasia marked an inline comment as done. Anastasia added inline comments. Comment at: clang/test/CodeGenOpenCL/relaxed-fpmath.cl:21 +float fused_mad(float a, float b, float c) { + // NORMAL: @llvm.fmuladd.f32 + // FAST: fmul fast float Anastasia wrote: >

[PATCH] D80315: Fix CC1 command line options mapping into fast-math flags.

Anastasia added inline comments. Comment at: clang/test/CodeGenOpenCL/relaxed-fpmath.cl:14 // FINITE: fdiv nnan ninf float - // UNSAFE: fdiv nnan nsz float + // UNSAFE: fdiv reassoc nsz arcp afn float // MAD: fdiv float michele.scandale wrote: > This

[PATCH] D89372: [OpenCL] Remove unused extensions

Anastasia added inline comments. Comment at: clang/include/clang/Basic/OpenCLExtensions.def:16 // // If the extensions are to be enumerated without the supported OpenCL version, // define OPENCLEXT(ext) where ext is the name of the extension. yaxunl wrote: >

[PATCH] D89372: [OpenCL] Remove unused extensions

Anastasia added a comment. In D89372#2330822 , @yaxunl wrote: > In D89372#2330362 , @Anastasia wrote: > >> In D89372#2330217 , @yaxunl wrote: >> >>> With this change, clang

[PATCH] D89372: [OpenCL] Remove unused extensions

Anastasia added a comment. In D89372#2332853 , @jvesely wrote: > `cl_khr_byte_addressable_stores` changes language semantics. without it, > pointer dereferences of types smaller than 32 bits are illegal. Ok, does it mean that we are missing to diagnose

[PATCH] D62574: Add support for target-configurable address spaces.

Anastasia added a comment. In D62574#2249817 , @ebevhan wrote: > In D62574#2242471 , @Anastasia wrote: > >> The only thing is that it would be good to test the new target setting logic >> somehow... do you have

[PATCH] D89143: [OpenCL][Docs] Improved description of the supported language functionality.

Anastasia created this revision. Anastasia added reviewers: azabaznov, svenvh. Herald added subscribers: ebevhan, yaxunl. Anastasia requested review of this revision. As suggested on RFC: http://lists.llvm.org/pipermail/cfe-dev/2020-October/066932.html https://reviews.llvm.org/D89143 Files:

[PATCH] D89143: [OpenCL][Docs] Improved description of the supported language functionality.

Anastasia added inline comments. Comment at: clang/docs/UsersManual.rst:2718 +Clang only supports the full OpenCL profile, and not `the embedded profile +`_. + I am surprised

[PATCH] D89520: Don't permit array bound constant folding in OpenCL.

Anastasia added a comment. > Permitting non-standards-driven "do the best you can" constant-folding > of array bounds is permitted solely as a GNU compatibility feature. We > should not be doing it in any language mode that is attempting to be > conforming. > > From

[PATCH] D89372: [OpenCL] Remove unused extensions

Anastasia added a comment. In D89372#2333937 , @jvesely wrote: > In D89372#2332997 , @Anastasia wrote: > >> In D89372#2332853 , @jvesely wrote: >> >>>

[PATCH] D89372: [OpenCL] Remove unused extensions

Anastasia added a comment. In D89372#2334728 , @jvesely wrote: > In D89372#2334225 , @Anastasia wrote: > >>> >> >> Ok, so the pragma is supposed to control the pointer dereferencing which >> seems like a valid

[PATCH] D89372: [OpenCL] Remove unused extensions

Anastasia added a comment. In D89372#2335627 , @jvesely wrote: > In D89372#2335027 , @Anastasia wrote: > >> In D89372#2334728 , @jvesely wrote: >> >>> In D89372#2334225

[PATCH] D89520: Don't permit array bound constant folding in OpenCL.

Anastasia accepted this revision. Anastasia added a comment. This revision is now accepted and ready to land. LGTM! Thanks Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D89520/new/ https://reviews.llvm.org/D89520

[PATCH] D89520: Don't permit array bound constant folding in OpenCL.

Anastasia added a comment. In D89520#2335628 , @rsmith wrote: > In D89520#2334477 , @Anastasia wrote: > >>> I couldn't find any spec justification for accepting the kinds of cases >>> that D20090

[PATCH] D88300: [OpenCL] Initial patch for OpenCL C 3.0 support

Anastasia added a comment. I think it should be ok to proceed with this now. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D88300/new/ https://reviews.llvm.org/D88300 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[PATCH] D89372: [OpenCL] Remove unused extensions

Anastasia added a comment. Yes, this is a group of extensions that doesn't seem to change anything in the kernel language. So if the macro is available I don't understand how it can be used to do anything different in the kernel code because it just doesn't modify anything in the kernel code.

[PATCH] D89372: [OpenCL] Remove unused extensions

Anastasia added a comment. In D89372#2330217 , @yaxunl wrote: > With this change, clang basically will have no knowledge about the removed > extensions, i.e., it will not know which extension is supported in which > version of OpenCL and have no way to

[PATCH] D88300: [OpenCL] Initial patch for OpenCL C 3.0 support

This revision was automatically updated to reflect the committed changes. Closed by commit rG71d3b7ec7b62: [OpenCL] Add new compilation mode for OpenCL 3.0. (authored by Anastasia). Herald added a project: clang. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION

[PATCH] D89372: [OpenCL] Remove unused extensions

Anastasia added inline comments. Comment at: clang/include/clang/Basic/OpenCLExtensions.def:74 OPENCLEXT_INTERNAL(cl_khr_mipmap_image_writes, 200, ~0U) -OPENCLEXT_INTERNAL(cl_khr_srgb_image_writes, 200, ~0U) OPENCLEXT_INTERNAL(cl_khr_subgroups, 200, ~0U)

[PATCH] D86626: [OpenCL][Docs] 10.x release notes

Anastasia added a subscriber: mantognini. Anastasia added a comment. @hans, would you be able to commit this to the release branch? PS, as I am away from next week I am looping in @mantognini for any follow up. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D86626/new/

[PATCH] D86626: [OpenCL][Docs] 10.x release notes

Anastasia closed this revision. Anastasia added a comment. https://reviews.llvm.org/rGdae9fe408793def8a49f5e1d10d2a859627785e3 CHANGES SINCE LAST ACTION https://reviews.llvm.org/D86626/new/ https://reviews.llvm.org/D86626 ___ cfe-commits mailing

[PATCH] D86626: [OpenCL][Docs] 10.x release notes

Anastasia updated this revision to Diff 287984. Anastasia added a comment. - Addressed comments from Sven. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D86626/new/ https://reviews.llvm.org/D86626 Files: clang/docs/ReleaseNotes.rst Index: clang/docs/ReleaseNotes.rst

[PATCH] D86626: [OpenCL][Docs] 10.x release notes

Anastasia updated this revision to Diff 287985. Anastasia added a comment. Fixed extra space CHANGES SINCE LAST ACTION https://reviews.llvm.org/D86626/new/ https://reviews.llvm.org/D86626 Files: clang/docs/ReleaseNotes.rst Index: clang/docs/ReleaseNotes.rst

[PATCH] D86626: [OpenCL][Docs] 10.x release notes

Anastasia created this revision. Anastasia added reviewers: svenvh, arsenm, AlexeySotkin, hans. Herald added subscribers: ebevhan, jfb, yaxunl. Anastasia requested review of this revision. Herald added a subscriber: wdng. Summary of major changes for OpenCL support in clang 11.

[PATCH] D62574: Add support for target-configurable address spaces.

Anastasia added a comment. Herald added a subscriber: bjope. This change looks good to me in general conceptually as it is completing missing logic in clang that let's targets to customize the address space behavior! The change also looks good from the implementation side apart from some small

[PATCH] D88300: [OpenCL] Initial patch for OpenCL C 3.0 support

Anastasia accepted this revision. Anastasia added a comment. This revision is now accepted and ready to land. LGTM! Thanks! Even though I don't imagine the discussion on the RFC (http://lists.llvm.org/pipermail/cfe-dev/2020-September/066883.html) will affect this functionality I think it's good

[PATCH] D80574: [ExtVector] Support ExtVectorType conditional operator

Anastasia added inline comments. Comment at: clang/docs/LanguageExtensions.rst:481 =yes yes yes yes -:? [#]_ yes --yes -- +?: yes --yes

[PATCH] D80574: [ExtVector] Support ExtVectorType conditional operator

Anastasia added inline comments. Comment at: clang/lib/Sema/SemaExpr.cpp:7484 + // Only ext vector is allowed + if (const auto *VecCondTy = Cond->getType()->getAs()) { +QualType EleTy = VecCondTy->getElementType(); myhsu wrote: > Anastasia wrote: > > Why

[PATCH] D80574: [ExtVector] Support ExtVectorType conditional operator

Anastasia accepted this revision. Anastasia added a comment. This revision is now accepted and ready to land. LGTM! Thanks! Please address small documentation nitpick before committing... Btw does your change fix this bug: https://bugs.llvm.org/show_bug.cgi?id=33103 Comment

[PATCH] D79781: [OpenCL] Add cl_khr_extended_subgroup extensions

Anastasia accepted this revision. Anastasia added a comment. In D79781#2063440 , @PiotrFusik wrote: > Bumped the OpenCL version from 1.2 to 2.0. Great! Thanks! Feel free to go ahead and commit this! Can you please add a link to the bug describing

[PATCH] D80932: [SYCL] Make default address space a superset of OpenCL address spaces.

Anastasia added a comment. Why? Default address space is normally an address space of automatic storage i.e. `private` in OpenCL. If you look at the address space map of targets most of them map default and private address spaces to the same value. Converting between private and other named

[PATCH] D89372: [OpenCL] Remove unused extensions

Anastasia added a comment. In D89372#2341638 , @mantognini wrote: > I don't want to stop the wider discussion, that being said I think I've > addressed the comment regarding the content of this PR. Let me know if the > latest version is fine or needs

[PATCH] D89909: [SYCL] Implement SYCL address space attributes handling

Anastasia added a comment. In the RFC it has been discussed to either use target address spaces or perhaps to introduce a new attribute to reflect a semantic needed for SYCL, but it seems to me in this change you are building on top of the existing language address space attribute with new

[PATCH] D62574: Initial draft of target-configurable address spaces.

Anastasia added a comment. > This was also only an initial concept. I think that even once all the issues > with the patch have been ironed out, it would require a round of wider review > since it's a fairly hefty API change. You don't always need a super polished prototype to justify adding

[PATCH] D62574: Initial draft of target-configurable address spaces.

Anastasia added a comment. In D62574#2136423 , @ebevhan wrote: > It seems that D70605 attempted to > ameliorate the issues that I observed (pointer-conversion doing too much), > but it didn't manage to solve the problem

[PATCH] D85429: [OpenCL] Allow for variadic macros in C++ for OpenCL

This revision was automatically updated to reflect the committed changes. Closed by commit rG3c8a4ee0764c: [OpenCL] Remove warning for variadic macros in C++ for OpenCL. (authored by Anastasia). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION

[PATCH] D85429: [OpenCL] Allow for variadic macros in C++ for OpenCL

Anastasia added a comment. Can you extend test test/Preprocessor/macro_variadic.cl to cover C++ for OpenCL mode, otherwise LGTM! Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D85429/new/ https://reviews.llvm.org/D85429

[PATCH] D62574: Add support for target-configurable address spaces.

Anastasia added a comment. In D62574#2210503 , @ebevhan wrote: > I think this works now. It should probably be given a few more reviewers to > have a look. Do you have some suggestions, @Anastasia ? Great! I will look at this again within a week or so.

[PATCH] D82756: Port some floating point options to new option marshalling infrastructure

Anastasia added inline comments. Comment at: clang/test/CodeGen/fp-function-attrs.cpp:2 +// RUN: %clang_cc1 -triple x86_64-linux-gnu -ffast-math -ffinite-math-only -menable-unsafe-fp-math \ +// RUN: -menable-no-infs -menable-no-nans -fno-signed-zeros -freciprocal-math \ +//

[PATCH] D85429: [OpenCL] Allow for variadic macros in C++ for OpenCL

Anastasia accepted this revision. Anastasia added a comment. This revision is now accepted and ready to land. LGTM! Thanks CHANGES SINCE LAST ACTION https://reviews.llvm.org/D85429/new/ https://reviews.llvm.org/D85429 ___ cfe-commits mailing list

[PATCH] D82756: Port some floating point options to new option marshalling infrastructure

Anastasia added inline comments. Comment at: clang/include/clang/Driver/Options.td:1176 +defm reciprocal_math : OptInFFlag< "reciprocal-math", "Allow division operations to be reassociated", "", "", [], "LangOpts->AllowRecip">; +def fapprox_func : Flag<["-"], "fapprox-func">,

[PATCH] D82781: [OpenCL] Fix missing address space deduction in template variables

Anastasia accepted this revision. Anastasia added a comment. This revision is now accepted and ready to land. LGTM! Thanks! CHANGES SINCE LAST ACTION https://reviews.llvm.org/D82781/new/ https://reviews.llvm.org/D82781 ___ cfe-commits mailing

[PATCH] D82781: [OpenCL] Fix missing address space deduction in template variables

Anastasia added inline comments. Comment at: clang/lib/Sema/SemaTemplateInstantiateDecl.cpp:3628 + // FIXME: This may not be the best approach, as the correct type (including + // address space) is available in D, but the type in D may not be reliable Is

[PATCH] D82781: [OpenCL] Fix missing address space deduction in template variables

This revision was automatically updated to reflect the committed changes. Closed by commit rG6050c156ab4f: [OpenCL] Defer addr space deduction for dependent type. (authored by Anastasia). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D82781/new/

[PATCH] D82781: [OpenCL] Fix missing address space deduction in template variables

Anastasia added a comment. So if I understand this correctly when the template is instantiated we don't have `QualType` with the address space deduced initially during parsing of a template global variable? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION

[PATCH] D82313: [OpenCL] Reject block arguments

Anastasia added inline comments. Comment at: clang/test/SemaOpenCL/invalid-block.cl:31 typedef int (^bl_t)(void); -bl_t f3(bl_t bl); // expected-error{{declaring function return value of type 'bl_t' (aka 'int (__generic ^const)(void)') is not allowed}} +bl_t f3a(int); //

[PATCH] D82313: [OpenCL] Reject block arguments

Anastasia accepted this revision. Anastasia added a comment. This revision is now accepted and ready to land. LGTM! Thanks! CHANGES SINCE LAST ACTION https://reviews.llvm.org/D82313/new/ https://reviews.llvm.org/D82313 ___ cfe-commits mailing

[PATCH] D80932: [SYCL] Make default address space a superset of OpenCL address spaces.

Anastasia added a subscriber: rjmccall. Anastasia added a comment. In D80932#2083185 , @bader wrote: > In D80932#2080631 , @Anastasia wrote: > > > > @Anastasia, if we make this change specific to SYCL mode, will it

[PATCH] D80932: [SYCL] Make default address space a superset of OpenCL address spaces.

Anastasia added a comment. > @Anastasia, if we make this change specific to SYCL mode, will it address > your concerns? I can't answer this question for the reasons I have explained above. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D80932/new/

[PATCH] D80932: [SYCL] Make default address space a superset of OpenCL address spaces.

Anastasia added a comment. In D80932#2073542 , @Naghasan wrote: > In D80932#2072064 , @Anastasia wrote: > > > In D80932#2071321 , @bader wrote: > > > > > In D80932#2068863

[PATCH] D80932: [SYCL] Make default address space a superset of OpenCL address spaces.

Anastasia requested changes to this revision. Anastasia added a comment. This revision now requires changes to proceed. In D80932#2071321 , @bader wrote: > In D80932#2068863 , @Anastasia wrote: > > > > > > > > >

[PATCH] D79781: [OpenCL] Add cl_khr_extended_subgroup extensions

Anastasia added a comment. In D79781#2070998 , @PiotrFusik wrote: > > Great! Thanks! Feel free to go ahead and commit this! > > Thanks. Can someone commit this for me, please? Also to 10.0 if possible? Ok, I can commit this. I am afraid the window for

[PATCH] D81608: Fix incorrect call to ExprResult::get()

Anastasia accepted this revision. Anastasia added a comment. This revision is now accepted and ready to land. LGTM! Thanks! Great spot! Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D81608/new/ https://reviews.llvm.org/D81608

[PATCH] D79781: [OpenCL] Add cl_khr_extended_subgroup extensions

This revision was automatically updated to reflect the committed changes. Closed by commit rG4a4402f0d721: [OpenCL] Add cl_khr_extended_subgroup extensions. (authored by Anastasia). Herald added a project: clang. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION

[PATCH] D83665: [OpenCL] Fixed missing address space for templated copy constructor

Anastasia accepted this revision. Anastasia added a comment. This revision is now accepted and ready to land. LGTM! Thanks CHANGES SINCE LAST ACTION https://reviews.llvm.org/D83665/new/ https://reviews.llvm.org/D83665 ___ cfe-commits mailing

[PATCH] D82756: Port some floating point options to new option marshalling infrastructure

Anastasia added inline comments. Comment at: clang/test/CodeGen/fp-function-attrs.cpp:2 +// RUN: %clang_cc1 -triple x86_64-linux-gnu -ffast-math -ffinite-math-only -menable-unsafe-fp-math \ +// RUN: -menable-no-infs -menable-no-nans -fno-signed-zeros -freciprocal-math \ +//

[PATCH] D83665: [OpenCL] Fixed missing address space for templated copy constructor

Anastasia added inline comments. Comment at: clang/lib/Sema/SemaTemplateDeduction.cpp:3811 + if(S.getLangOpts().OpenCL) +ArgType = S.deduceOpenCLPointeeAddrSpace(ArgType); ArgType = S.Context.getLValueReferenceType(ArgType); I feel we can

[PATCH] D83665: [OpenCL] Fixed missing address space for templated copy constructor

This revision was automatically updated to reflect the committed changes. Closed by commit rG92fa91bb4029: [OpenCL] Fixed missing address space for templated copy constructor. (authored by Anastasia). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION

[PATCH] D83665: [OpenCL] Fixed missing address space for templated copy constructor

Anastasia added inline comments. Comment at: clang/lib/Sema/SemaTemplateDeduction.cpp:3811 + if(S.getLangOpts().OpenCL) +ArgType = S.deduceOpenCLPointeeAddrSpace(ArgType); ArgType = S.Context.getLValueReferenceType(ArgType); olestrohm wrote:

[PATCH] D94021: [OpenCL] Add clang extension for function pointers

This revision was automatically updated to reflect the committed changes. Closed by commit rG4fde2b6a0c08: [OpenCL] Add clang extension for function pointers. (authored by Anastasia). Herald added a project: clang. Changed prior to commit: https://reviews.llvm.org/D94021?vs=314411=314963#toc

[PATCH] D94188: [OpenCL] Documentation for experimental C++ libraries support

Anastasia added a comment. This patch is uploaded on top of https://reviews.llvm.org/D93942 CHANGES SINCE LAST ACTION https://reviews.llvm.org/D94188/new/ https://reviews.llvm.org/D94188 ___ cfe-commits mailing list cfe-commits@lists.llvm.org

[PATCH] D94027: [OpenCL] Add clang extension for variadic functions

This revision was automatically updated to reflect the committed changes. Closed by commit rG0e874fc014be: [OpenCL] Add clang extension for variadic functions. (authored by Anastasia). Herald added a project: clang. Changed prior to commit: https://reviews.llvm.org/D94027?vs=314869=314964#toc

[PATCH] D94188: [OpenCL] add documentation for experimental C++ libraries support

Anastasia created this revision. Anastasia added a reviewer: mantognini. Herald added subscribers: ebevhan, yaxunl. Anastasia requested review of this revision. Started a new doc section about the OpenCL experimental features and described ongoing work on C++ libraries e.g. type traits.

[PATCH] D89909: [SYCL] Implement SYCL address space attributes handling

Anastasia added a comment. In D89909#2403069 , @bader wrote: >> Did anyone conclude there that the language address spaces should be added >> for SYCL? I can't see any of this. In fact I don't even think there was any >> conclusion on the RFC. You

[PATCH] D89869: [OpenCL] Define OpenCL feature macros for all versions

Anastasia added inline comments. Comment at: clang/include/clang/Basic/OpenCLOptions.h:37 + // OpenCL Version + unsigned CLVer = 120; + bool IsOpenCLCPlusPlus = false; Anastasia wrote: > Anastasia wrote: > > azabaznov wrote: > > > Anastasia wrote: > > > > Ok,

[PATCH] D92231: [OpenCL] Implement extended subgroups fully in headers

Anastasia created this revision. Anastasia added reviewers: azabaznov, AlexeySotkin, mantognini, svenvh, PiotrFusik. Herald added subscribers: ebevhan, yaxunl. Anastasia requested review of this revision. Extended subgroups extensions were added in https://reviews.llvm.org/D79781, however, in

[PATCH] D92004: [OpenCL] add CL 3.0 optional feature support to opencl-c.h

Anastasia added a comment. Thanks! This looks much cleaner. I am still unclear what should we do with testing though. Comment at: clang/lib/Headers/opencl-c-base.h:284 memory_scope_work_group = __OPENCL_MEMORY_SCOPE_WORK_GROUP, +#if defined(__OPENCL_CPP_VERSION__) ||

[PATCH] D92244: [OpenCL] Prevent adding vendor extensions for all targets

Anastasia created this revision. Anastasia added reviewers: svenvh, AlexeySotkin, azabaznov. Herald added subscribers: ebevhan, yaxunl. Anastasia requested review of this revision. Some extensions were defined in the headers without guarding by the target. This commit fixes this and also removed

[PATCH] D92091: [OpenCL] Allow pointer-to-pointer kernel args beyond CL 1.2

Anastasia accepted this revision. Anastasia added a comment. This revision is now accepted and ready to land. LGTM! Thanks! The testing can be improved before committing! Comment at: clang/lib/Sema/SemaDecl.cpp:8638 // array, this recursive call only happens once.

[PATCH] D92091: [OpenCL] Allow pointer-to-pointer kernel args beyond CL 1.2

Anastasia added inline comments. Comment at: clang/lib/Sema/SemaDecl.cpp:8638 // array, this recursive call only happens once. return getOpenCLKernelParameterType(S, QualType(UnderlyingTy, 0)); } Btw I am surprised that we recurse to check the

[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

[PATCH] D90928: [OpenCL] Check for extension string extension lookup

Anastasia accepted this revision. Anastasia added a comment. This revision is now accepted and ready to land. Great! LGTM! Thanks! Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D90928/new/ https://reviews.llvm.org/D90928

[PATCH] D92231: [OpenCL] Implement extended subgroups fully in headers

Anastasia added a comment. In D92231#2425323 , @Anastasia wrote: > In D92231#2425305 , @PiotrFusik > wrote: > >> The specification for these extensions was edited by Ben Ashbaugh @Intel. >> I've asked him about

[PATCH] D89909: [SYCL] Implement SYCL address space attributes handling

Anastasia added a comment. In D89909#2423750 , @bader wrote: >> It was mentioned that the changes in the type system with address spaces is >> undesirable for SYCL because you indend to parse existing C++ code as-is. >> This contradicts the intended

[PATCH] D92721: [PATCH] [clang] Create SPIRABIInfo to enable SPIR_FUNC calling convention

Anastasia added a comment. In D92721#2437941 , @mibintc wrote: > There are many RuntimeCalls that are created in Clang, including _read_pipe, > all the OpenMP runtime calls, etc. Shall they all have their calling > conventions set from the ABIInfo?

[PATCH] D92231: [OpenCL] Implement extended subgroups fully in headers

Anastasia added inline comments. Comment at: clang/lib/Headers/opencl-c-base.h:17-23 +#define cl_khr_subgroup_extended_types +#define cl_khr_subgroup_non_uniform_vote +#define cl_khr_subgroup_ballot +#define cl_khr_subgroup_non_uniform_arithmetic +#define cl_khr_subgroup_shuffle

[PATCH] D92231: [OpenCL] Implement extended subgroups fully in headers

Anastasia updated this revision to Diff 310227. Anastasia added a comment. - Set all macros to value 1 CHANGES SINCE LAST ACTION https://reviews.llvm.org/D92231/new/ https://reviews.llvm.org/D92231 Files: clang/include/clang/Basic/OpenCLExtensions.def clang/lib/Headers/opencl-c-base.h

[PATCH] D92231: [OpenCL] Implement extended subgroups fully in headers

Anastasia added inline comments. Comment at: clang/lib/Headers/opencl-c-base.h:17-23 +#define cl_khr_subgroup_extended_types +#define cl_khr_subgroup_non_uniform_vote +#define cl_khr_subgroup_ballot +#define cl_khr_subgroup_non_uniform_arithmetic +#define cl_khr_subgroup_shuffle

[PATCH] D92004: [OpenCL] add CL 3.0 optional feature support to opencl-c.h

Anastasia added a comment. In D92004#2412953 , @airlied wrote: > this file has never been clang-format clean, happy to make changes if > reviewer decides they are needed. This has not been considered a conventional clang source so to say, so the coding

[PATCH] D92033: [OpenCL] Move kernel arg type tests into one file

Anastasia accepted this revision. Anastasia added a comment. This revision is now accepted and ready to land. LGTM! Thanks Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D92033/new/ https://reviews.llvm.org/D92033

[PATCH] D92004: [OpenCL] add CL 3.0 optional feature support to opencl-c.h

Anastasia added a subscriber: azabaznov. Anastasia added a comment. I assume your change depends on some other changes that add the feature macro definitions. So I think we should link the other changes in at some point. CCing to @azabaznov here who is working on the features too. Repository:

[PATCH] D92004: [OpenCL] add CL 3.0 optional feature support to opencl-c.h

Anastasia added a subscriber: svenvh. Anastasia added a comment. > It will need some decent review and maybe some testing by other CL users to > make sure I've haven't messed up when used with a fully featured CL 3.0 stack. Clang functionality is expected to be tested in llvm-project and with

<    5   6   7   8   9   10   11   12   13   14   >