[PATCH] D58569: [libclang] Avoid crashing when getting layout info of an undeduced type.

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/D58569/new/ https://reviews.llvm.org/D58569

[PATCH] D58634: [PR40778] Generate address space conversion when binding reference to a temporary value in different address space

Anastasia marked an inline comment as done. Anastasia added inline comments. Comment at: lib/CodeGen/CGCall.cpp:4067 + IRFuncTy->getParamType(FirstIRArg)->isPointerTy()) +V = Builder.CreatePointerBitCastOrAddrSpaceCast( +V, IRFuncTy->getPa

[PATCH] D58658: [OpenCL] Fix assertion due to blocks

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/D58658/new/ https://reviews.llvm.org/D58658 ___ cfe-commits mailing lis

[PATCH] D58708: [PR40778] Preserve addr space in Derived to Base cast

Anastasia created this revision. Anastasia added a reviewer: rjmccall. Herald added a subscriber: ebevhan. The address space for the Base class pointer when up-casting from Derived should be taken from the Derived class pointer. https://reviews.llvm.org/D58708 Files: lib/CodeGen/CGClass.cpp

[PATCH] D58719: [PR40778][Sema] Adjust address space of operands in builtin operators

Anastasia created this revision. Anastasia added reviewers: rjmccall, ebevhan. Adjust address space for references and pointer operands of builtin operators. Currently this patch only changes addr space for OpenCL in assignment operator, that is needed to fix the bug in the testcase reported in:

[PATCH] D58719: [PR40778][Sema] Adjust address space of operands in builtin operators

Anastasia updated this revision to Diff 188566. Anastasia edited the summary of this revision. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D58719/new/ https://reviews.llvm.org/D58719 Files: lib/Sema/SemaOverload.cpp test/CodeGenOpenCLCXX/addrspace-operators.cl Index: test/CodeGenO

[PATCH] D58236: Make address space conversions a bit stricter.

Anastasia accepted this revision. Anastasia added a comment. This revision is now accepted and ready to land. LGTM! Thanks a lot for fixing this old bug! Btw, do you plan to look at generalizing this to C++ as well? I don't feel we need anything for mixing OpenCL with GNU style address spaces a

[PATCH] D58666: [OpenCL] Undefine cl_intel_planar_yuv extension

Anastasia added inline comments. Comment at: test/SemaOpenCL/extension-begin.cl:26 + #ifndef IMPLICIT_INCLUDE #include "extension-begin.h" sidorovd wrote: > Anastasia wrote: > > Can we also test that macro `my_ext` is not defined here but defined above? > > >

[PATCH] D58346: [Sema] Change addr space diagnostics in casts to follow C++ style

Anastasia updated this revision to Diff 188577. Anastasia added a comment. - Added a comment to explain OpenCL check. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D58346/new/ https://reviews.llvm.org/D58346 Files: include/clang/Basic/DiagnosticSemaKinds.td lib/Sema/SemaCast.cpp t

[PATCH] D58346: [Sema] Change addr space diagnostics in casts to follow C++ style

Anastasia marked an inline comment as done. Anastasia added inline comments. Comment at: lib/Sema/SemaCast.cpp:2309 +auto DestPointeeTypeWithoutAS = Self.Context.removeAddrSpaceQualType( +DestPointeeType.getCanonicalType()); +return Self.Context.hasSameType(SrcPoi

[PATCH] D58666: [OpenCL] Undefine cl_intel_planar_yuv extension

Anastasia added inline comments. Comment at: test/SemaOpenCL/extension-begin.cl:26 + #ifndef IMPLICIT_INCLUDE #include "extension-begin.h" sidorovd wrote: > Anastasia wrote: > > sidorovd wrote: > > > Anastasia wrote: > > > > Can we also test that macro `my_ext`

[PATCH] D58346: [Sema] Change addr space diagnostics in casts to follow C++ style

Anastasia marked an inline comment as done. Anastasia added inline comments. Comment at: lib/Sema/SemaCast.cpp:2309 +auto DestPointeeTypeWithoutAS = Self.Context.removeAddrSpaceQualType( +DestPointeeType.getCanonicalType()); +return Self.Context.hasSameType(SrcPoi

[PATCH] D58236: Make address space conversions a bit stricter.

Anastasia added a comment. > Along those lines, in general, the normal C rules should allow casting `foo*` > to `bar*` for any object types foo and bar, even if foo and bar are pointers > with address spaces, like `__local int *` and `__global int *`. I don't see > anything in the OpenCL stand

[PATCH] D58060: Fix diagnostic for addr spaces in static_cast

Anastasia added a comment. Btw, I have changed the diagnostic wording... does this change make sense now? CHANGES SINCE LAST ACTION https://reviews.llvm.org/D58060/new/ https://reviews.llvm.org/D58060 ___ cfe-commits mailing list cfe-commits@list

[PATCH] D58666: [OpenCL] Undefine cl_intel_planar_yuv extension

Anastasia accepted this revision. Anastasia added a comment. This revision is now accepted and ready to land. LGTM! I am ok with this change to remove the macro from the common header. I don't think it belongs to there. However, I believe this functionality should be better represented in the ve

[PATCH] D58236: Make address space conversions a bit stricter.

Anastasia added a comment. In D58236#1414069 , @efriedma wrote: > > I think trying to reject code that is doing something dangerous is a good > > thing! > > Refusing to compile code which is suspicious, but not forbidden by the > specification, will like

[PATCH] D58346: [Sema] Change addr space diagnostics in casts to follow C++ style

Anastasia added a comment. In D58346#1413863 , @rjmccall wrote: > Hmm. Yeah, Embedded C allows these casts, so contra my previous comment, I > think we can't make them ill-formed outside of OpenCL mode. Ok, would these rules apply in regular C99 mode t

[PATCH] D58060: Fix diagnostic for addr spaces in reference binding

Anastasia updated this revision to Diff 189306. Anastasia retitled this revision from "Fix diagnostic for addr spaces in static_cast" to "Fix diagnostic for addr spaces in reference binding". Anastasia edited the summary of this revision. Anastasia added a comment. - Fixed incorrect diagnostic in

[PATCH] D58634: [PR40778] Generate address space conversion when binding reference to a temporary value in different address space

Anastasia updated this revision to Diff 189313. Anastasia added a comment. - Implement the fix correctly by added an extra address space conversion step after binding the reference CHANGES SINCE LAST ACTION https://reviews.llvm.org/D58634/new/ https://reviews.llvm.org/D58634 Files: includ

[PATCH] D58708: [PR40778] Preserve addr space in Derived to Base cast

Anastasia updated this revision to Diff 189347. Anastasia marked an inline comment as done. Anastasia added a comment. Moved adding address space to `DestType` earlier to cover pointer and non-pointer case. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D58708/new/ https://reviews.llvm.

[PATCH] D58708: [PR40778] Preserve addr space in Derived to Base cast

Anastasia added inline comments. Comment at: lib/Sema/SemaExpr.cpp:2670 } else { DestType = DestRecordType; FromRecordType = FromType; rjmccall wrote: > This path (when the object is a gl-value) also needs an address-space > qualifier, so you

[PATCH] D58060: Fix diagnostic for addr spaces in reference binding

Anastasia added inline comments. Comment at: test/SemaOpenCLCXX/address-space-references.cl:7 +// can't detect this case and therefore fails. +//int bar(const unsigned int &i); + ebevhan wrote: > Is there a reason the declaration is commented out? If it's just a

[PATCH] D58060: Fix diagnostic for addr spaces in reference binding

Anastasia updated this revision to Diff 189351. Anastasia marked an inline comment as done. Anastasia added a comment. Un-commented the line in the test CHANGES SINCE LAST ACTION https://reviews.llvm.org/D58060/new/ https://reviews.llvm.org/D58060 Files: include/clang/Basic/DiagnosticSemaK

[PATCH] D58346: [Sema] Change addr space diagnostics in casts to follow C++ style

Anastasia updated this revision to Diff 189361. Anastasia added a comment. Updates FiXME explaining why C++ mode is more permissive. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D58346/new/ https://reviews.llvm.org/D58346 Files: include/clang/Basic/DiagnosticSemaKinds.td lib/Sema/S

[PATCH] D58346: [Sema] Change addr space diagnostics in casts to follow C++ style

Anastasia added a comment. In D58346#1417983 , @rjmccall wrote: > In the abstract, it would be nice to warn about casts that always have UB > because the address spaces don't overlap; however, I'm worried about how > people might be using address spaces

[PATCH] D58708: [PR40778] Preserve addr space in Derived to Base cast

Anastasia updated this revision to Diff 189371. Anastasia added a comment. Use common pointer type. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D58708/new/ https://reviews.llvm.org/D58708 Files: lib/CodeGen/CGClass.cpp lib/Sema/SemaExpr.cpp test/CodeGenOpenCLCXX/addrspace-derive

[PATCH] D58708: [PR40778] Preserve addr space in Derived to Base cast

Anastasia updated this revision to Diff 189470. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D58708/new/ https://reviews.llvm.org/D58708 Files: lib/CodeGen/CGClass.cpp lib/Sema/SemaExpr.cpp test/CodeGenOpenCLCXX/addrspace-derived-base.cl Index: test/CodeGenOpenCLCXX/addrspace-der

[PATCH] D58708: [PR40778] Preserve addr space in Derived to Base cast

Anastasia marked an inline comment as done. Anastasia added inline comments. Comment at: lib/Sema/SemaExpr.cpp:2671 DestType = Context.getPointerType(DestRecordType); FromRecordType = FromType->getPointeeType(); PointerConversions = true; rjm

[PATCH] D58346: [Sema] Change addr space diagnostics in casts to follow C++ style

Anastasia updated this revision to Diff 189474. Anastasia added a comment. Restructure code with early return. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D58346/new/ https://reviews.llvm.org/D58346 Files: include/clang/Basic/DiagnosticSemaKinds.td lib/Sema/SemaCast.cpp test/Cod

[PATCH] D58236: Make address space conversions a bit stricter.

Anastasia added a comment. In D58236#1417429 , @efriedma wrote: > In D58236#1416765 , @Anastasia wrote: > > > In D58236#1414069 , @efriedma > > wrote: > > > > > > I think tr

[PATCH] D58719: [PR40778][Sema] Adjust address space of operands in builtin operators

Anastasia updated this revision to Diff 189527. Anastasia added a comment. Herald added a subscriber: jdoerfert. I now create overloads for all address spaces that are being called. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D58719/new/ https://reviews.llvm.org/D58719 Files: lib/Se

[PATCH] D58708: [PR40778] Preserve addr space in Derived to Base cast

Anastasia closed this revision. Anastasia added a comment. Committed in r355606. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D58708/new/ https://reviews.llvm.org/D58708 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.

[PATCH] D59219: [PR41007][OpenCL] Allow printf and toolchain reserved variadic functions in C++

Anastasia created this revision. Anastasia added a reviewer: neil.hickey. Herald added subscribers: ebevhan, yaxunl. As for OpenCL C, we will allow `printf` and other variadic functions (prefixed by "__") in C++ mode. https://reviews.llvm.org/D59219 Files: lib/Sema/SemaType.cpp test/SemaOp

[PATCH] D57464: Generalize method overloading on addr spaces to C++

Anastasia added a comment. In D57464#1421493 , @ebevhan wrote: > Any more input on this? I think not. :( But I am wondering if we could proceed for now in some general direction and then make any improvements later. Probably the biggest part of this pa

[PATCH] D59299: [libclang] Expose aligned() attribute.

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/D59299/new/ https://reviews.llvm.org/D59299

[PATCH] D59367: [Sema] Adjust address space of operands in remaining builtin operators

Anastasia created this revision. Anastasia added reviewers: rjmccall, bevinh. Herald added subscribers: jdoerfert, ebevhan. Fix address space of reference operand in the remaining builtin compound assignment operators. https://reviews.llvm.org/D59367 Files: lib/Sema/SemaOverload.cpp test/C

[PATCH] D59219: [PR41007][OpenCL] Allow printf and toolchain reserved variadic functions in C++

Anastasia marked an inline comment as done. Anastasia added inline comments. Comment at: cfe/trunk/test/SemaOpenCL/extensions.cl:31 // RUN: %clang_cc1 %s -triple amdgcn-unknown-unknown -verify -pedantic -fsyntax-only -cl-std=CL2.0 -finclude-default-header -// RUN: %clang_cc1 %s

[PATCH] D59426: [PR41010][OpenCL] Allow OpenCL C style vector initialization in C++

Anastasia created this revision. Anastasia added reviewers: rjmccall, bader. Herald added subscribers: jdoerfert, ebevhan, yaxunl. Not sure it's the right approach but the idea is that we would like to accept vector contraction syntax from OpenCL C. This commit fixes Sema checks when creating a

[PATCH] D59486: [OpenCL] Improve testing of default header in C++ mode

Anastasia created this revision. Anastasia added a reviewer: bader. Herald added subscribers: ebevhan, yaxunl. Moved testing of the default header into the Driver test and also added a test line for C++ mode in printf test. Follow up from https://reviews.llvm.org/D59219 https://reviews.llvm.or

[PATCH] D59492: [OpenCL] Allow variadic macros as Clang feature

Anastasia updated this revision to Diff 191093. Anastasia added a comment. Better wording CHANGES SINCE LAST ACTION https://reviews.llvm.org/D59492/new/ https://reviews.llvm.org/D59492 Files: docs/UsersManual.rst include/clang/Basic/DiagnosticLexKinds.td lib/Lex/PPDirectives.cpp test

[PATCH] D59492: [OpenCL] Allow variadic macros as Clang feature

Anastasia created this revision. Anastasia added a reviewer: bader. Herald added subscribers: ebevhan, yaxunl. Variadic macros are used for debugging and therefore it is desirable to accept the code that uses them. There was a discussion about this in OpenCL spec bugs: https://github.com/Khrono

[PATCH] D59492: [OpenCL] Allow variadic macros as Clang feature

Anastasia updated this revision to Diff 191094. Anastasia added a comment. Fixed comment CHANGES SINCE LAST ACTION https://reviews.llvm.org/D59492/new/ https://reviews.llvm.org/D59492 Files: docs/UsersManual.rst include/clang/Basic/DiagnosticLexKinds.td lib/Lex/PPDirectives.cpp test/

[PATCH] D59493: [OpenCL] Generate 'unroll.enable' metadata for __attribute__((opencl_unroll_hint))

Anastasia accepted this revision. Anastasia added a comment. This revision is now accepted and ready to land. LGTM! Thanks! The wording in spec is confusing btw because it says: > This attribute qualifier can be used to specify full unrolling or partial > unrolling by a specified amount. May b

[PATCH] D59493: [OpenCL] Generate 'unroll.enable' metadata for __attribute__((opencl_unroll_hint))

Anastasia added a comment. PS, I am just saying that I guess leaving this to the compiler is more helpful than explicitly requiring the full unroll. However, spec contradicts itself by first mentioning the full unroll and then stating that compiler will determines the unrolling factor. Reposi

[PATCH] D59486: [OpenCL] Improve testing of default header in C++ mode

Anastasia updated this revision to Diff 191100. Anastasia added a comment. Moved testing of default header in C++ mode to test/Headers/opencl-c-header.cl CHANGES SINCE LAST ACTION https://reviews.llvm.org/D59486/new/ https://reviews.llvm.org/D59486 Files: test/Driver/include-default-header

[PATCH] D59486: [OpenCL] Improve testing of default header in C++ mode

Anastasia marked an inline comment as done. Anastasia added inline comments. Comment at: test/Driver/include-default-header.cl:2 +// RUN: %clang -save-temps -x cl -Xclang -cl-std=CL2.0 -Xclang -finclude-default-header -emit-llvm -S -### %s 2>&1 | FileCheck %s +// RUN: %clang -sa

[PATCH] D59492: [OpenCL] Allow variadic macros as Clang feature

Anastasia added a comment. In D59492#1433796 , @arsenm wrote: > Should it be downgraded to a warning about an extension instead of just > removing it? What would you suggest to put in a warning message? Clang normally doesn't warn about extensions...

[PATCH] D59486: [OpenCL] Improve testing of default header in C++ mode

Anastasia marked an inline comment as done. Anastasia added inline comments. Comment at: test/Headers/opencl-c-header.cl:57-65 char f(char x) { -#if __OPENCL_C_VERSION__ != CL_VERSION_2_0 +#if !defined(__OPENCL_CPP_VERSION__) && (__OPENCL_C_VERSION__ != CL_VERSION_2_0) retur

[PATCH] D59544: [OpenCL] Minor improvements in default header testing

Anastasia created this revision. Anastasia added a reviewer: bader. Herald added subscribers: ebevhan, yaxunl. Suggested in https://reviews.llvm.org/D59486 https://reviews.llvm.org/D59544 Files: test/Headers/opencl-c-header.cl Index: test/Headers/opencl-c-header.cl =

[PATCH] D59367: [Sema] Adjust address space of operands in remaining builtin operators

Anastasia added a comment. In D59367#1434353 , @rjmccall wrote: > This patch LGTM. > > You might consider adding tests for weird cases like class types with > conversion operators to reference types. To a certain extent that sort of > thing is unimpleme

[PATCH] D59492: [OpenCL] Allow variadic macros as Clang feature

Anastasia added a comment. In D59492#1434822 , @arsenm wrote: > In D59492#1434636 , @Anastasia wrote: > > > In D59492#1433796 , @arsenm wrote: > > > > > Should it be downgrad

[PATCH] D59492: [OpenCL] Allow variadic macros as Clang feature

Anastasia updated this revision to Diff 191366. Anastasia added a comment. Instead of removing the diagnostic completely change into a warning in pedantic mode. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D59492/new/ https://reviews.llvm.org/D59492 Files: include/clang/Basic/Diagno

[PATCH] D59603: [PR40707][PR41011][OpenCL] Allow addr space spelling without double underscore in C++ mode

Anastasia created this revision. Anastasia added reviewers: svenvh, rjmccall. Herald added subscribers: jdoerfert, ebevhan, yaxunl. For backwards compatibility we should allow alternative spelling of address spaces - `private`, `local`, `global`, `constant`, `generic`. Note that in order to acce

[PATCH] D53705: [OpenCL] Postpone PSV address space diagnostic

Anastasia added a comment. Herald added a subscriber: ebevhan. Herald added a project: clang. Btw, I have created a patch that allows non-underscore prefixed spelling for address spaces in C++ for OpenCL: https://reviews.llvm.org/D59603 I assume the error becomes less critical however it remains

[PATCH] D59603: [PR40707][PR41011][OpenCL] Allow addr space spelling without double underscore in C++ mode

Anastasia updated this revision to Diff 191665. Anastasia added a comment. Updated test to use root namespace (commented by Ronan). CHANGES SINCE LAST ACTION https://reviews.llvm.org/D59603/new/ https://reviews.llvm.org/D59603 Files: include/clang/Basic/TokenKinds.def lib/Parse/ParseDecl

[PATCH] D59603: [PR40707][PR41011][OpenCL] Allow addr space spelling without double underscore in C++ mode

Anastasia added a comment. In D59603#1436794 , @keryell wrote: > I was a little bit worried about > > struct top_level { int i; }; > > private ::top_level a; > > > > but it should be fine because in that case we have a `tok::coloncolon` Yes, inde

[PATCH] D59646: [PR40778][PR41157][OpenCL] Prevent implicit initialization of local address space objects

Anastasia created this revision. Anastasia added reviewers: rjmccall, bader. Herald added a subscriber: ebevhan. Anastasia retitled this revision from "[PR40778][PR41157] Prevent implicit initialization of local address space objects" to "[PR40778][PR41157][OpenCL] Prevent implicit initialization

[PATCH] D58236: Make address space conversions a bit stricter.

Anastasia added a comment. In D58236#1437690 , @ebevhan wrote: > Any more input on this? > > I could redo the patch to simply fix the bug and not make the conversions > stricter, if that's preferable. I was playing a bit with some examples of enum with

[PATCH] D57464: Generalize method overloading on addr spaces to C++

Anastasia added a comment. > I think I would lean towards the latter since it means less fudging around > with a whole bunch of unrelated methods. Do @rjmccall or @rsmith have any > further opinions on this? Ok, I can change the patch to prototype this approach. I might need some example tes

[PATCH] D59492: [OpenCL] Allow variadic macros as Clang feature

Anastasia updated this revision to Diff 192082. Anastasia added a comment. Changed diagnostic wording to indicate that this feature is a Clang extension. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D59492/new/ https://reviews.llvm.org/D59492 Files: include/clang/Basic/DiagnosticLexK

[PATCH] D59492: [OpenCL] Allow variadic macros as Clang feature

Anastasia marked an inline comment as done. Anastasia added inline comments. Comment at: include/clang/Basic/DiagnosticLexKinds.td:397 +def ext_pp_opencl_variadic_macros : Extension< + "variadic macros not supported in OpenCL">; arsenm wrote: > Maybe rephrase

[PATCH] D59646: [PR40778][PR41157][OpenCL] Prevent implicit initialization of local address space objects

Anastasia updated this revision to Diff 192087. Anastasia marked 2 inline comments as done. Anastasia added a comment. Fixed typo in the comment. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D59646/new/ https://reviews.llvm.org/D59646 Files: lib/Sema/SemaDecl.cpp test/CodeGenOpenCL

[PATCH] D59646: [PR40778][PR41157][OpenCL] Prevent implicit initialization of local address space objects

Anastasia added inline comments. Comment at: lib/Sema/SemaDecl.cpp:11648-11651 +// In OpenCL we don't allow to initialize objects in local address space. +if (getLangOpts().OpenCL && +Var->getType().getAddressSpace() == LangAS::opencl_local) + return; ---

[PATCH] D59646: [PR40778][PR41157][OpenCL] Prevent implicit initialization of local address space objects

Anastasia marked an inline comment as done. Anastasia added inline comments. Comment at: test/CodeGenOpenCLCXX/local_addrspace_init.cl:12 + __local int i; + __local C ii; + //FIXME: In OpenCL C we don't accept initializers for local address space variables. b

[PATCH] D59492: [OpenCL] Allow variadic macros as Clang feature

Anastasia closed this revision. Anastasia added a comment. Committed in r356987. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D59492/new/ https://reviews.llvm.org/D59492 ___ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.

[PATCH] D59874: [PR41247] Fixed parsing of private keyword in C++

Anastasia created this revision. Anastasia added reviewers: rjmccall, jsji. Herald added a subscriber: ebevhan. In C++ `private` shouldn't be parsed as a valid address space keyword. This only fixes C++ part, in OpenCL we should still prevent ICE on the reported code example, but I will fix it s

[PATCH] D59603: [PR40707][PR41011][OpenCL] Allow addr space spelling without double underscore in C++ mode

Anastasia added a comment. In D59603#1443651 , @jsji wrote: > Looks like this may cause some unexpected failures. See > https://bugs.llvm.org/show_bug.cgi?id=41247 for more details. Thanks! I have created a review for the fix: https://reviews.llvm.org/D

[PATCH] D59874: [PR41247] Fixed parsing of private keyword in C++

Anastasia updated this revision to Diff 192485. Anastasia added a comment. Herald added a subscriber: jdoerfert. Extended test case and explained the intention of the test. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D59874/new/ https://reviews.llvm.org/D59874 Files: lib/Parse/Parse

[PATCH] D53809: Fix invalid address space generation for clk_event_t

Anastasia added inline comments. Herald added a subscriber: ebevhan. Herald added a project: clang. Comment at: lib/CodeGen/CGBuiltin.cpp:3614 + ClkEvent = ClkEvent->getType()->isIntegerTy() + ? Builder.CreateBitOrPointerCast(ClkEvent, EventPtrTy) +

[PATCH] D59988: [PR41276] Generate address space cast of 'this' for objects attributed by an address space in C++

Anastasia created this revision. Anastasia added reviewers: rjmccall, brunodefraine. Herald added a subscriber: ebevhan. The example from the bugzilla triggered two issues: 1. In qualification conversion we are creating an address space conversion for non-pointer and non-reference type. 2. We ar

[PATCH] D59988: [PR41276] Generate address space cast of 'this' for objects attributed by an address space in C++

Anastasia marked an inline comment as done. Anastasia added inline comments. Comment at: lib/CodeGen/CGClass.cpp:2025 +ThisPtr = +Builder.CreatePointerBitCastOrAddrSpaceCast(This.getPointer(), NewType); } I am a bit unsure if `performAddrSpaceCast

[PATCH] D59985: Re-fix invalid address space generation for clk_event_t arguments of enqueue_kernel builtin function

Anastasia added inline comments. Comment at: lib/CodeGen/CGBuiltin.cpp:3711 + EventList = EventList->getType()->isIntegerTy() + ? Builder.CreateIntToPtr(EventList, EventPtrTy) + : Builder.CreatePointerCast(EventList, EventPtrTy); ---

[PATCH] D59988: [PR41276] Generate address space cast of 'this' for objects attributed by an address space in C++

Anastasia updated this revision to Diff 193281. Anastasia added a comment. - Use `AggValueSlot` in the constructor call generation to store/retrieve address space of 'this'. - Fixed detecting the address space conversion while performing qualification conversion. CHANGES SINCE LAST ACTION ht

[PATCH] D60193: [OpenCL] Added addrspace_cast operator

Anastasia created this revision. Anastasia added reviewers: rjmccall, ebevhan. Herald added a subscriber: yaxunl. This change adds extra cast operator `addrspace_cast` described earlier in this RFC: http://lists.llvm.org/pipermail/cfe-dev/2018-December/060546.html This operator is intended for c

[PATCH] D59985: Re-fix invalid address space generation for clk_event_t arguments of enqueue_kernel builtin function

Anastasia added inline comments. Comment at: lib/CodeGen/CGBuiltin.cpp:3711 + EventList = EventList->getType()->isIntegerTy() + ? Builder.CreateIntToPtr(EventList, EventPtrTy) + : Builder.CreatePointerCast(EventList, EventPtrTy); ---

[PATCH] D60193: [OpenCL] Added addrspace_cast operator

Anastasia marked an inline comment as done. Anastasia added inline comments. Comment at: include/clang/Basic/TokenKinds.def:564 +// OpenCL addrspace_cast operator +KEYWORD(addrspace_cast , KEYOPENCLCXX) + If I mark it as CXX keyword this will make it

[PATCH] D59646: [PR40778][PR41157][OpenCL] Prevent implicit initialization of local address space objects

Anastasia updated this revision to Diff 193474. Anastasia added a comment. Improved comment about initializers in __local addr space. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D59646/new/ https://reviews.llvm.org/D59646 Files: lib/Sema/SemaDecl.cpp test/CodeGenOpenCLCXX/addrspac

[PATCH] D59985: Re-fix invalid address space generation for clk_event_t arguments of enqueue_kernel builtin function

Anastasia added a comment. In D59985#1453312 , @AlexeySotkin wrote: > Alternative way to fix it is to use `isNullPointerConstant` like we do in > `SemaOpenCLBuiltinEnqueueKernel`. So in case we have a zero literal value we > can emit `ConstantPointerNul

[PATCH] D59985: Re-fix invalid address space generation for clk_event_t arguments of enqueue_kernel builtin function

Anastasia added a comment. In D59985#1454660 , @AlexeySotkin wrote: > In D59985#1454629 , @Anastasia wrote: > > > In D59985#1453312 , @AlexeySotkin > > wrote: > > > > > Alt

[PATCH] D59985: [OpenCL] Re-fix invalid address space generation for clk_event_t arguments of enqueue_kernel builtin function

Anastasia accepted this revision. Anastasia added a comment. This revision is now accepted and ready to land. LGTM! Great! Thanks! Comment at: lib/CodeGen/CGBuiltin.cpp:3709 + llvm::Value *EventWaitList = nullptr; + if (E->getArg(4)->isNullPointerConstant( +

[PATCH] D60379: Make precompiled headers reproducible

Anastasia added inline comments. Comment at: lib/Serialization/ASTWriter.cpp:4283 + // Sort to allow reproducible .pch files - https://bugs.debian.org/877359 + std::map> sortedOpenCLTypeExtMap; for (const auto &I : SemaRef.OpenCLTypeExtMap) { lebedev.ri wrot

[PATCH] D60454: [OpenCL] Prevent mangling kernel functions

Anastasia created this revision. Anastasia added reviewers: rjmccall, bader. Herald added subscribers: ebevhan, yaxunl. Kernel function names have to be preserved as in the original source to be able to access them from the host API side. This patch adds restriction to kernels that prevents them

[PATCH] D60379: Make precompiled headers reproducible

Anastasia added inline comments. Comment at: lib/Serialization/ASTWriter.cpp:4283 + // Sort to allow reproducible .pch files - https://bugs.debian.org/877359 + std::map> sortedOpenCLTypeExtMap; for (const auto &I : SemaRef.OpenCLTypeExtMap) { riccibruno wrot

[PATCH] D60455: [SYCL] Add support for SYCL device attributes

Anastasia requested changes to this revision. Anastasia added a comment. This revision now requires changes to proceed. I was just wondering since SYCL is intended to be a single source C++ for OpenCL and this attribute is for internal use is it possible to just reuse existing OpenCL kernel attr

[PATCH] D60455: [SYCL] Add support for SYCL device attributes

Anastasia added a comment. > Our current approach is to add an attribute, which SYCL runtime will use to > mark code passed to `cl::sycl::handler::parallel_for` as "kernel functions". > Obviously runtime library can't mark `foo` as "device" code - this is a > compiler job: to traverse all sym

[PATCH] D58236: Make address space conversions a bit stricter.

Anastasia added a comment. In D58236#1466263 , @ebevhan wrote: > Well, it doesn't seem to me like there is consensus on prohibiting nested > address space conversion like this. > > I can simply redo the patch to only include the bugfix on implicit > conv

[PATCH] D60455: [SYCL] Add support for SYCL device attributes

Anastasia added inline comments. Comment at: clang/include/clang/Basic/AttrDocs.td:286 +help. + }]; +} keryell wrote: > aaron.ballman wrote: > > I'm still not entirely certain how I would know what to mark and how. From > > the description, it sounds like whoev

[PATCH] D60763: Prototype OpenCL BIFs using Tablegen

Anastasia added a subscriber: joey. Anastasia added a comment. Not related to this patch but it might be good to start thinking about testing this functionality properly. In the past we haven't tested the header because it would take a lot of testing time. So I would suggest we keep a light mini

[PATCH] D60764: Add clang cc1 option to generate OpenCL builtin functions

Anastasia added inline comments. Comment at: clang/include/clang/Driver/CC1Options.td:755 HelpText<"Include the default header file for OpenCL">; +def fgenerate_opencl_builtin: Flag<["-"], "fgenerate-opencl-builtin">, + HelpText<"Generate OpenCL builtin functions using Tableg

[PATCH] D60775: [libclang] Expose ext_vector_type

Anastasia accepted this revision. Anastasia added a comment. This revision is now accepted and ready to land. LGTM! Thanks! Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D60775/new/ https://reviews.llvm.org/D60775 ___

[PATCH] D60778: Make precompiled headers reproducible by switching OpenCL extension to std::map

Anastasia created this revision. Anastasia added reviewers: lebedev.ri, sylvestre.ledru, riccibruno. Herald added subscribers: ebevhan, JDevlieghere, yaxunl. As discussed in https://reviews.llvm.org/D60379 let's use std::map to store OpenCL extensions data structure. Not sure how to test this th

[PATCH] D60379: Make precompiled headers reproducible

Anastasia added a comment. FYI, I switched to `std::map` in this review: https://reviews.llvm.org/D60778 @sylvestre.ledru do you think it's possible to apply this patch and see if it work for your bug? Btw I am still confused about the reproducibility - does clang produce the same PCH at leas

[PATCH] D60455: [SYCL] Add support for SYCL device attributes

Anastasia added a comment. In D60455#1469150 , @aaron.ballman wrote: > In D60455#1468714 , @bader wrote: > > > In D60455#1468386 , @Fznamznon > > wrote: > > > > > > Ok, my

[PATCH] D60455: [SYCL] Add support for SYCL device attributes

Anastasia added a comment. In D60455#1468386 , @Fznamznon wrote: > In D60455#1467018 , @Anastasia wrote: > > > Just to understand how this will work. I would imagine you can have a > > device function definition pr

[PATCH] D60778: Make precompiled headers reproducible by switching OpenCL extension to std::map

Anastasia added a comment. In D60778#1468825 , @lebedev.ri wrote: > > Not sure how to test this though? I guess we can trust that std::map is > > always sorted just as it says in its description. > > You could add a test that contains several entries in `

[PATCH] D60778: Make precompiled headers reproducible by switching OpenCL extension to std::map

Anastasia added a comment. In D60778#1470188 , @riccibruno wrote: > Maybe, but is there an equivalent to `getTypeID` for declarations ? `getDeclID` is used in the first patch... although now I am thinking may be original patch is a better approach? CH

[PATCH] D60455: [SYCL] Add support for SYCL device attributes

Anastasia added a comment. > > >> I think what we are missing currently is a thorough analysis/comparison >> between SYCL device mode and OpenCL kernel language mode to understand >> what's the best implementation strategy. That would apply to many other >> features: kernel function restric

[PATCH] D60778: Make precompiled headers reproducible by switching OpenCL extension to std::map

Anastasia added a comment. In D60778#1470176 , @lebedev.ri wrote: > In D60778#1470152 , @Anastasia wrote: > > > In D60778#1468825 , @lebedev.ri > > wrote: > > > > > > Not su

[PATCH] D60835: [Serialization] Stable serialization order for OpenCLTypeExtMap and OpenCLDeclExtMap

Anastasia added a comment. In D60835#1470805 , @riccibruno wrote: > By the way, I am wondering about how much this is tested. I did look quickly > in `test/PCH` and it appears that there are only 3 (short) tests : > `ocl_types.cl`, `opencl-extensions.cl`

[PATCH] D60835: [Serialization] Stable serialization order for OpenCLTypeExtMap and OpenCLDeclExtMap

Anastasia accepted this revision. Anastasia added a comment. This revision is now accepted and ready to land. >> We could still go for something like the following but accept that some a >> random failure might happen not necessarily on a commit that introduces it? > > I am not sure that this is

<    1   2   3   4   5   6   7   8   9   10   >