Page MenuHomePhabricator
Feed Advanced Search

Fri, Jul 3

Anastasia added inline comments to D82781: [OpenCL] Fix missing address space deduction in template variables.
Fri, Jul 3, 11:17 AM · Restricted Project
Anastasia added inline comments to D82174: [OpenCL] Add global_device and global_host address spaces.
Fri, Jul 3, 11:17 AM

Mon, Jun 29

Anastasia added a comment to D82781: [OpenCL] Fix missing address space deduction in template variables.

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?

Mon, Jun 29, 9:42 AM · Restricted Project

Fri, Jun 26

Anastasia added inline comments to D82174: [OpenCL] Add global_device and global_host address spaces.
Fri, Jun 26, 3:46 AM
Anastasia accepted D82313: [OpenCL] Reject block arguments.

LGTM! Thanks!

Fri, Jun 26, 3:13 AM · Restricted Project

Tue, Jun 23

Anastasia added a comment to D82174: [OpenCL] Add global_device and global_host address spaces.

TODO: update address space numerical values for SPIR target
Regarding the TODO. Still I like an idea of detached address spaces a little bit more, but I see your point. I would love to check how it works with SPIR-V address space mapping in SPIR-V to LLVM IR translator. I know, it shall have a little impact on a clang work, but still what to see the work I have to do there first (5 and 6 are already occupied there).

Tue, Jun 23, 10:43 AM
Anastasia added inline comments to D82313: [OpenCL] Reject block arguments.
Tue, Jun 23, 10:10 AM · Restricted Project

Fri, Jun 19

Anastasia added inline comments to D82174: [OpenCL] Add global_device and global_host address spaces.
Fri, Jun 19, 8:08 AM
Anastasia added inline comments to D82174: [OpenCL] Add global_device and global_host address spaces.
Fri, Jun 19, 8:05 AM
Anastasia added a comment to D82174: [OpenCL] Add global_device and global_host address spaces.

Btw could you upload a full diff, please?
https://llvm.org/docs/Phabricator.html#requesting-a-review-via-the-web-interface
It will simplify the review....

Fri, Jun 19, 8:05 AM
Anastasia added a comment to D82174: [OpenCL] Add global_device and global_host address spaces.

I think you should also test the conversions of address spaces and it would be good to add a cl file i.e. OpenCL C level test.

Fri, Jun 19, 7:32 AM

Thu, Jun 18

Anastasia added a comment to D68994: [RFC] Redefine `convergent` in terms of dynamic instances.

What is the status of this change?

I still want to pursue a proper modeling of convergent that would probably express that the invalid optimizations that you're likely to see are forbidden. However, the model described here has some issues, and I hope to introduce a slight variation that addresses those issue.

As a matter of pragmatism, I wonder whether we shouldn't just already disable those problematic optimizations today...

Thu, Jun 18, 9:13 AM · Restricted Project

Thu, Jun 11

Anastasia accepted D81608: Fix incorrect call to ExprResult::get().

LGTM! Thanks! Great spot!

Thu, Jun 11, 1:47 PM · Restricted Project

Wed, Jun 10

Anastasia updated subscribers of D80932: [SYCL] Make default address space a superset of OpenCL address spaces..

@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.

Sorry, I'm not sure that I get your concern correctly, so let me clarify: is it allowing conversion between pointers w/ and w/o address space annotation in non-SYCL mode or using OpenCL address space attributes in SYCL mode?

Just to help you to understand the proposed design, I created the full patch for address space handling in SYCL: https://github.com/bader/llvm/pull/18. There are few CodeGen tests validating LLVM IR for SPIR target. Fee free to ask any questions on this PR.

Wed, Jun 10, 12:13 PM · Restricted Project

Mon, Jun 8

Anastasia added a comment to D80932: [SYCL] Make default address space a superset of OpenCL address spaces..

@Anastasia, if we make this change specific to SYCL mode, will it address your concerns?

Mon, Jun 8, 12:41 PM · Restricted Project

Jun 4 2020

Anastasia added a comment to D80932: [SYCL] Make default address space a superset of OpenCL address spaces..

Why? Can you explain what you are trying to achieve with this?

I think @asavonic can provide more detailed answer, but IIRC we spent a lot time trying to marry template meta-programming with OpenCL address space deductions, but even simplest template functions from C++ standard library breaks compilation. It's important to note one important difference in design goals for SYCL and C++ for OpenCL. SYCL aims to enable compilation of regular C++ as much as possible where as one of the C++ for OpenCL goals is to keep compatibility with OpenCL C. These two goals might lead to different design decisions.

I don't see a contradiction in those goals. We plan to support C++ libraries with C++ for OpenCL of course with functionality that is accepted by conformant OpenCL implementations. For example, libraries that use virtual functions leading to function pointers are not going to work portably in OpenCL devices. If SYCL aims to compile to conformant OpenCL devices then it should not be very different I imagine?

(Edited a bit)

There is a fundamental difference (given the direction taken for OpenCL), OpenCL mode actively modifies user's types (C and C++ for OpenCL AFAIK). So inside a function, this:

int var;

becomes

VarDecl  var '__private int'

Which is fine in C where you can't really do much with your types, but this has a massive and destructive effect in C++. For instance this does not compile in C++ for OpenCL:

void foo() {
    int var; // '__private int' not 'int'
    int* ptr1 = &var; // '__generic int* __private' not 'int*'
    decltype(var)* ptr2 = ptr1; // error: cannot initialize a variable of type 'decltype(var) *__private' (aka '__private int *__private') with an lvalue of type '__generic int *__private'
}
Jun 4 2020, 2:57 PM · Restricted Project
Anastasia added a comment to D77220: [SYCL] Enable Open CL types required for implementing the SYCL headers..

Seems reasonable from the OpenCL side.

Jun 4 2020, 5:57 AM
Anastasia committed rG4a4402f0d721: [OpenCL] Add cl_khr_extended_subgroup extensions. (authored by Anastasia).
[OpenCL] Add cl_khr_extended_subgroup extensions.
Jun 4 2020, 5:32 AM
Anastasia closed D79781: [OpenCL] Add cl_khr_extended_subgroup extensions.
Jun 4 2020, 5:30 AM · Restricted Project

Jun 3 2020

Anastasia added a comment to D79781: [OpenCL] Add cl_khr_extended_subgroup extensions.

Great! Thanks! Feel free to go ahead and commit this!

Thanks. Can someone commit this for me, please? Also to 10.0 if possible?

Jun 3 2020, 1:10 PM · Restricted Project
Anastasia requested changes to D80932: [SYCL] Make default address space a superset of OpenCL address spaces..

Why? Can you explain what you are trying to achieve with this?

I think @asavonic can provide more detailed answer, but IIRC we spent a lot time trying to marry template meta-programming with OpenCL address space deductions, but even simplest template functions from C++ standard library breaks compilation. It's important to note one important difference in design goals for SYCL and C++ for OpenCL. SYCL aims to enable compilation of regular C++ as much as possible where as one of the C++ for OpenCL goals is to keep compatibility with OpenCL C. These two goals might lead to different design decisions.

Jun 3 2020, 1:10 PM · Restricted Project

Jun 2 2020

Anastasia added a comment to D80932: [SYCL] Make default address space a superset of OpenCL address spaces..

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 address space is not allowed in OpenCL see section 6.5. I don't believe this change is doing anything legitimate.

Jun 2 2020, 8:14 AM · Restricted Project

Jun 1 2020

Anastasia accepted D80574: [ExtVector] Support ExtVectorType conditional operator.

LGTM! Thanks! Please address small documentation nitpick before committing...

Jun 1 2020, 12:59 PM · Restricted Project
Anastasia accepted D79781: [OpenCL] Add cl_khr_extended_subgroup extensions.

Bumped the OpenCL version from 1.2 to 2.0.

Jun 1 2020, 7:28 AM · Restricted Project
Anastasia updated subscribers of D79781: [OpenCL] Add cl_khr_extended_subgroup extensions.
Jun 1 2020, 6:55 AM · Restricted Project

May 29 2020

Anastasia accepted D79781: [OpenCL] Add cl_khr_extended_subgroup extensions.

LGTM! Thanks!

May 29 2020, 9:12 AM · Restricted Project
Anastasia added inline comments to D80574: [ExtVector] Support ExtVectorType conditional operator.
May 29 2020, 8:39 AM · Restricted Project
Anastasia added inline comments to D79781: [OpenCL] Add cl_khr_extended_subgroup extensions.
May 29 2020, 7:34 AM · Restricted Project

May 28 2020

Anastasia abandoned D80440: [OpenCL] Prevent fused mul and add by default.
May 28 2020, 9:15 AM
Anastasia added inline comments to D79781: [OpenCL] Add cl_khr_extended_subgroup extensions.
May 28 2020, 8:42 AM · Restricted Project
Anastasia added inline comments to D80574: [ExtVector] Support ExtVectorType conditional operator.
May 28 2020, 8:07 AM · Restricted Project

May 22 2020

Anastasia created D80440: [OpenCL] Prevent fused mul and add by default.
May 22 2020, 8:01 AM
Anastasia added inline comments to D80416: [RFC][OpenCL] Set fp contract flag on -cl-mad-enable.
May 22 2020, 8:01 AM
Anastasia added inline comments to D80416: [RFC][OpenCL] Set fp contract flag on -cl-mad-enable.
May 22 2020, 5:18 AM
Anastasia added inline comments to D80416: [RFC][OpenCL] Set fp contract flag on -cl-mad-enable.
May 22 2020, 5:18 AM
Anastasia added a comment to D80416: [RFC][OpenCL] Set fp contract flag on -cl-mad-enable.

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 precision. Is contracting into something less precise allowed?

May 22 2020, 3:00 AM

May 21 2020

Anastasia retitled D80416: [RFC][OpenCL] Set fp contract flag on -cl-mad-enable from [RCF][OpenCL] Set fp contract flag on -cl-mad-enable to [RFC][OpenCL] Set fp contract flag on -cl-mad-enable.
May 21 2020, 3:43 PM
Anastasia added inline comments to D80416: [RFC][OpenCL] Set fp contract flag on -cl-mad-enable.
May 21 2020, 3:43 PM
Anastasia created D80416: [RFC][OpenCL] Set fp contract flag on -cl-mad-enable.
May 21 2020, 3:43 PM
Anastasia added inline comments to D80315: Fix CC1 command line options mapping into fast-math flags..
May 21 2020, 1:32 PM · Restricted Project
Anastasia added inline comments to D79781: [OpenCL] Add cl_khr_extended_subgroup extensions.
May 21 2020, 12:59 PM · Restricted Project

May 20 2020

Anastasia updated subscribers of D80317: [SYCL] Prohibit arithmetic operations for incompatible pointers.
May 20 2020, 2:18 PM · Restricted Project

May 19 2020

Anastasia updated subscribers of D79781: [OpenCL] Add cl_khr_extended_subgroup extensions.
May 19 2020, 5:54 AM · Restricted Project

May 18 2020

Anastasia added inline comments to D79903: FastMathFlags.allowContract should be init from FPFeatures.allowFPContractAcrossStatement.
May 18 2020, 1:33 PM · Restricted Project
Anastasia added a comment to D79781: [OpenCL] Add cl_khr_extended_subgroup extensions.

Can you please add a reference to the document that described these extensions in the description of your patch. Thanks!

May 18 2020, 1:01 PM · Restricted Project
Anastasia committed rGa6a237f2046a: [OpenCL] Added addrspace_cast operator in C++ mode. (authored by Anastasia).
[OpenCL] Added addrspace_cast operator in C++ mode.
May 18 2020, 4:15 AM
Anastasia closed D60193: [OpenCL] Added addrspace_cast operator.
May 18 2020, 4:15 AM · Restricted Project

May 10 2020

Anastasia added inline comments to D60193: [OpenCL] Added addrspace_cast operator.
May 10 2020, 2:54 PM · Restricted Project
Anastasia updated the diff for D60193: [OpenCL] Added addrspace_cast operator.
  • Improved behavior by allowing casting between equivalent types.
  • Improved formatting.
  • Improved tests.
May 10 2020, 2:54 PM · Restricted Project

May 6 2020

Anastasia added inline comments to D60193: [OpenCL] Added addrspace_cast operator.
May 6 2020, 3:19 PM · Restricted Project
Anastasia added a comment to D60193: [OpenCL] Added addrspace_cast operator.

When compiling this I get the following warning:

clang/lib/StaticAnalyzer/Core/ExprEngine.cpp:1213:10: warning: enumeration value 'CXXAddrspaceCastExprClass' not handled in switch

The fix is probably to just add the missing case with the other *CastExprClass cases.

There's also a similar warning for clang/tools/libclang/CXCursor.cpp:132.

May 6 2020, 2:44 PM · Restricted Project
Anastasia updated the diff for D60193: [OpenCL] Added addrspace_cast operator.

Sorry for long latency. I have rebased the patch to the current master and addressed the comments from @mantognini too.

May 6 2020, 2:44 PM · Restricted Project

May 4 2020

Anastasia added a comment to D78979: OpenCL: Include builtin header by default.

Would it not become confusing since the builtins are going to be included by default? Should we rename the flag at least? Also ideally it should be documented in https://clang.llvm.org/docs/UsersManual.html#opencl-header

ah I guess if we leave it under -cc1 we will have the command line interface as follows:

  • Driver (without -cc1) adds OpenCL header by default that can be overridden by the flag added in this patch.
  • Frontend (with -cc1) doesn't add the header by default but there are two flags -fdeclare-opencl-builtins or -finclude-default-header that allow to include the header.

The name of -fdeclare-opencl-builtins becomes a bit non-intuitive, a more intuitive name would be something like -fopencl-tablegen-builtins perhaps or -fopencl-fast-builtins if we don't want to mention TableGen. But since it is still an experimental option, I have no objections against postponing the renaming until the option has reached maturity.

I vote for -fopencl-fast-builtins.

The main problem I'm trying to solve is that users shouldn't need to concern themselves with including any header, much less a choice between two internal implementation details. Switching the two internal header implementations seems OK to leave as a cc1 flag. The main question I think is what the spelling of how to disable whatever default header was chosen, and what the internal flags to switch the implementation look like.

So what's the agreement on spelling? Use -nostdinc/-nostdlib? Have 2 different cc1 flags for the header implementation switch? Surface/invert -fno-include-default-header?

May 4 2020, 9:37 AM

Apr 30 2020

Anastasia added a comment to D78979: OpenCL: Include builtin header by default.

I'm also wondering if using -nogpulib for the corresponding linker purpose was correct, since in the OpenCL case it's not really an offload target. Maybe this should switch to -nostdlib?

-nogpulib is fine since opencl compiler is in parallel with the device compiler of CUDA/HIP. The library it uses is the device library.

OpenCL can target other devices than GPUs, including CPUs and FPGAs, referring to gpulibs wrt opencl is a misnomer.

It would be nice to have some clarity as to how OpenCL is handled wrt clang frontend vs. clang driver.
OpenCL options are currently split between the two (e.g. cl-denorms-are-zero is only available in the driver and not the frontend)
There are 3 implementations of CL headers, two in clang which might or might not be included by default, and the 3rd one in libclc.

Apr 30 2020, 11:47 AM

Apr 29 2020

Anastasia added a comment to D78979: OpenCL: Include builtin header by default.

ah I guess if we leave it under -cc1 we will have the command line interface as follows:

  • Driver (without -cc1) adds OpenCL header by default that can be overridden by the flag added in this patch.
  • Frontend (with -cc1) doesn't add the header by default but there are two flags -fdeclare-opencl-builtins or -finclude-default-header that allow to include the header.

    Is my understanding correct? We should reflect this is the User Manual.

I think -finclude-default-header -fno-include-default-header better becomes both driver and -cc1 option since users are likely to use it with driver. It may also be used with other languages e.g. HIP.

Apr 29 2020, 12:21 PM
Anastasia added a comment to D78979: OpenCL: Include builtin header by default.

Would it not become confusing since the builtins are going to be included by default? Should we rename the flag at least? Also ideally it should be documented in https://clang.llvm.org/docs/UsersManual.html#opencl-header

ah I guess if we leave it under -cc1 we will have the command line interface as follows:

  • Driver (without -cc1) adds OpenCL header by default that can be overridden by the flag added in this patch.
  • Frontend (with -cc1) doesn't add the header by default but there are two flags -fdeclare-opencl-builtins or -finclude-default-header that allow to include the header.

The name of -fdeclare-opencl-builtins becomes a bit non-intuitive, a more intuitive name would be something like -fopencl-tablegen-builtins perhaps or -fopencl-fast-builtins if we don't want to mention TableGen. But since it is still an experimental option, I have no objections against postponing the renaming until the option has reached maturity.

Apr 29 2020, 12:21 PM

Apr 28 2020

Anastasia added a comment to D78979: OpenCL: Include builtin header by default.

I am looping in @svenvh to discuss this further. Sven, do you think we should rename this flag due to current proposed change? Should it be moved out of -cc1 too?

I would leave -fdeclare-opencl-builtins as it is, until it is complete and taken out of its "experimental" status. Then we can discuss if we want to use TableGen instead of the header as a default.

Would it not become confusing since the builtins are going to be included by default? Should we rename the flag at least? Also ideally it should be documented in https://clang.llvm.org/docs/UsersManual.html#opencl-header

Apr 28 2020, 6:56 AM
Anastasia added a comment to D78979: OpenCL: Include builtin header by default.

I am looping in @svenvh to discuss this further. Sven, do you think we should rename this flag due to current proposed change? Should it be moved out of -cc1 too?

I would leave -fdeclare-opencl-builtins as it is, until it is complete and taken out of its "experimental" status. Then we can discuss if we want to use TableGen instead of the header as a default.

Would it not become confusing since the builtins are going to be included by default? Should we rename the flag at least? Also ideally it should be documented in https://clang.llvm.org/docs/UsersManual.html#opencl-header

Apr 28 2020, 6:24 AM
Anastasia committed rGfe667e8522a6: [OpenCL] Fixed test for the cast operators. (authored by Anastasia).
[OpenCL] Fixed test for the cast operators.
Apr 28 2020, 4:47 AM
Herald added a project to D77923: OpenCL: Fix some missing predefined macros: Restricted Project.

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?

Apr 28 2020, 4:15 AM · Restricted Project
Anastasia updated subscribers of D78979: OpenCL: Include builtin header by default.

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 of flag naming decisions, or if we really need the
fno-include-default-header cc1 flag.

Apr 28 2020, 3:43 AM
Anastasia accepted D78777: [AST] Use PrintingPolicy for format string diagnosis.

LGTM! Thanks!

Apr 28 2020, 3:11 AM · Restricted Project

Apr 14 2020

Anastasia added a comment to D77923: OpenCL: Fix some missing predefined macros.

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.

Apr 14 2020, 8:32 AM · Restricted Project

Mar 26 2020

Anastasia added inline comments to D75685: Add MS Mangling for OpenCL Pipe types, add mangling test..
Mar 26 2020, 6:28 AM · Restricted Project
Anastasia added inline comments to D75685: Add MS Mangling for OpenCL Pipe types, add mangling test..
Mar 26 2020, 6:28 AM · Restricted Project
Anastasia added a comment to D76636: [RFC] Added type trait to remove address space qualifier from type.

Address spaces are actually defined in a number of standardized C extensions that are compatible with C++, such as the Embedded C specification, OpenCL, and so on. There's precedent for libc++ accepting work that supports this kind of C++-compatible extension in the past; for example, std::is_pointer looks through Objective-C's ARC type qualifiers. That said, (1) libc++ hasn't actually added new traits for such things before, just taught existing traits to handle them, and (2) I think this definition wouldn't actually work for cases like the OpenCL address spaces because they're not expressible as __attribute__((address_space(N))). (2) is fixable; (1) may be a reasonable place to draw the line on policy.

Regarding (2) (although it's probably not changing the major concerns) this exact implementation also works for OpenCL because we map the address space keywords to the attributes during the parsing. However, OpenCL currently doesn't support libcxx. :(

Ah, okay. Maybe it's one of the other languages that keeps its address spaces separate from address_space.

Regardless, if libc++ wants to have a policy of not adding new features that cover non-C++ features, that's a reasonable stance.

Mar 26 2020, 5:55 AM

Mar 25 2020

Anastasia added a comment to D75685: Add MS Mangling for OpenCL Pipe types, add mangling test..

Sorry for the delayed comments. It would be good to address those in a separate commit if possible.

Mar 25 2020, 10:16 AM · Restricted Project
Anastasia added a comment to D76636: [RFC] Added type trait to remove address space qualifier from type.

I agree with @EricWF here. Libc++ shouldn't become a repository of useful but non-standard utilities. It's useful to sometimes extend standard tools to non-standard concepts (like handling some Objective-C qualifiers when we can), but adding something new that hasn't been standardized is not really the business we want to be into.

However, @Anastasia , you could consider proposing the attribute for standardization, and if that makes the cut, then we'll be happy to implement it.

Cheers!

Mar 25 2020, 10:15 AM
Anastasia added a comment to D76636: [RFC] Added type trait to remove address space qualifier from type.

Address spaces are actually defined in a number of standardized C extensions that are compatible with C++, such as the Embedded C specification, OpenCL, and so on. There's precedent for libc++ accepting work that supports this kind of C++-compatible extension in the past; for example, std::is_pointer looks through Objective-C's ARC type qualifiers. That said, (1) libc++ hasn't actually added new traits for such things before, just taught existing traits to handle them, and (2) I think this definition wouldn't actually work for cases like the OpenCL address spaces because they're not expressible as __attribute__((address_space(N))). (2) is fixable; (1) may be a reasonable place to draw the line on policy.

Mar 25 2020, 9:43 AM

Mar 23 2020

Anastasia created D76636: [RFC] Added type trait to remove address space qualifier from type.
Mar 23 2020, 12:00 PM

Mar 12 2020

Anastasia added inline comments to D75685: Add MS Mangling for OpenCL Pipe types, add mangling test..
Mar 12 2020, 7:03 AM · Restricted Project

Mar 10 2020

Anastasia added inline comments to D75917: Expose llvm fence instruction as clang intrinsic.
Mar 10 2020, 9:46 AM · Restricted Project
Anastasia added inline comments to D75685: Add MS Mangling for OpenCL Pipe types, add mangling test..
Mar 10 2020, 5:12 AM · Restricted Project

Mar 4 2020

Anastasia added a comment to D75285: Mark restrict pointer or reference to const as invariant.

That is not true for two reasons: first, restrict guarantees that the variable is not accessed through any non-derived l-value within its scope, and that would certainly include from other threads; and second, it is undefined behavior for two threads to access the same object without synchronizing anyway (unless they're both just reading from it).

How about the cases where users cannot use restrict but they still want to mark a pointer as invariant? Or even though restrict is used but it is too complicated for alias analysis to deduce invariance?

Mar 4 2020, 10:38 AM

Mar 3 2020

Anastasia added a comment to D75285: Mark restrict pointer or reference to const as invariant.

Are you sure restrict alone isn't good enough? It doesn't directly tell you that the memory is invariant, but it's usually simple to prove that the memory isn't modified within the restrict scope, which might be sufficient.

Mar 3 2020, 4:35 AM

Feb 27 2020

Anastasia added a comment to D74910: [OpenCL] Remove spurious atomic_fetch_min/max builtins.

I would say if we are not aware of any test that this change breaks, let's go ahead and commit this?

Feb 27 2020, 4:53 AM · Restricted Project
Anastasia added a comment to D75125: [Docs][OpenCL] Release 10.0 notes for OpenCL.

Thanks for writing notes! Go ahead and push directly to the branch when you're ready.

Feb 27 2020, 3:46 AM
Anastasia added a comment to D75125: [Docs][OpenCL] Release 10.0 notes for OpenCL.

@hans, what is the current process for committing to the release branch? Would you be able to commit this or would you prefer that I commit myself?

Feb 27 2020, 3:42 AM

Feb 26 2020

Anastasia updated the diff for D75125: [Docs][OpenCL] Release 10.0 notes for OpenCL.

Addressed comments from Hans and Sven.

Feb 26 2020, 9:50 AM

Feb 25 2020

Anastasia added inline comments to D75125: [Docs][OpenCL] Release 10.0 notes for OpenCL.
Feb 25 2020, 8:37 AM
Anastasia added a reviewer for D75125: [Docs][OpenCL] Release 10.0 notes for OpenCL: hans.
Feb 25 2020, 8:37 AM
Anastasia created D75125: [Docs][OpenCL] Release 10.0 notes for OpenCL.
Feb 25 2020, 8:35 AM
Anastasia committed rGfa755d3e71ed: [Sema][C++] Propagate conversion kind to specialize the diagnostics (authored by Anastasia).
[Sema][C++] Propagate conversion kind to specialize the diagnostics
Feb 25 2020, 8:09 AM
Anastasia closed D74116: [Sema][C++] Propagate conversion type in order to specialize the diagnostics.
Feb 25 2020, 8:08 AM · Restricted Project

Feb 20 2020

Anastasia updated the diff for D74116: [Sema][C++] Propagate conversion type in order to specialize the diagnostics.
  • Always set isInvalid for all error cases.
  • Hoist setting isInvalid together with an error diagnostic.
  • Updated more tests.
Feb 20 2020, 6:59 AM · Restricted Project

Feb 19 2020

Anastasia added inline comments to D74116: [Sema][C++] Propagate conversion type in order to specialize the diagnostics.
Feb 19 2020, 12:14 PM · Restricted Project

Feb 18 2020

Anastasia updated the diff for D74116: [Sema][C++] Propagate conversion type in order to specialize the diagnostics.
  • Updated expected diagnostics for function pointer tests
  • Make DiagnoseAsignmentResult return true for all incompatible cases in C++
Feb 18 2020, 7:48 AM · Restricted Project

Feb 17 2020

Anastasia added inline comments to D74116: [Sema][C++] Propagate conversion type in order to specialize the diagnostics.
Feb 17 2020, 3:14 AM · Restricted Project

Feb 14 2020

Anastasia added a comment to D74116: [Sema][C++] Propagate conversion type in order to specialize the diagnostics.

It looks like there's already some type analysis in DiagnoseAssignmentResult to get a specialized diagnostic for certain cases of function-pointer assignment. That could probably be easily moved into CheckAssignmentConstraints by just adding a few more cases to AssignConvertResult.

One interesting effect I get after modifying this that some extra tests in C mode started to report function pointer instead of generic pointer warning. I feel this is because in checkPointerTypesForAssignment we use canonical types and in DiagnoseAssignmentResult we don't.

Feb 14 2020, 9:45 AM · Restricted Project
Anastasia updated the diff for D74116: [Sema][C++] Propagate conversion type in order to specialize the diagnostics.
  • Switched to using CheckAssignmentConstraints
  • Duplicated all extensions and warnings as errors for C++ mode
  • Added IncompatibleFunctionPointer
Feb 14 2020, 9:36 AM · Restricted Project

Feb 12 2020

Anastasia updated the diff for D74116: [Sema][C++] Propagate conversion type in order to specialize the diagnostics.

If I reuse the helper checkPointerTypesForAssignment I end up with lots of error turned into warnings, see example in
test/SemaCXX/addr-of-overloaded-function.cpp

Feb 12 2020, 4:50 AM · Restricted Project

Feb 7 2020

Anastasia committed rG6064f426a183: [OpenCL] Restrict addr space conversions in nested pointers (authored by Anastasia).
[OpenCL] Restrict addr space conversions in nested pointers
Feb 7 2020, 4:08 AM
Anastasia closed D73360: [OpenCL] Restrict address space conversions in nested pointers.
Feb 7 2020, 4:07 AM · Restricted Project
Anastasia added a comment to D74116: [Sema][C++] Propagate conversion type in order to specialize the diagnostics.

Hmm. The alternative approach, I suppose, would be to recognize that we're about to emit a generic error and just recheck assignment constraints to recompute the AssignConvertType.

Feb 7 2020, 2:56 AM · Restricted Project

Feb 6 2020

Anastasia added a comment to D73360: [OpenCL] Restrict address space conversions in nested pointers.

Okay, we can go with this for now, since it does fix a bug.

Feb 6 2020, 3:36 AM · Restricted Project
Anastasia created D74116: [Sema][C++] Propagate conversion type in order to specialize the diagnostics.
Feb 6 2020, 3:36 AM · Restricted Project
Anastasia updated the summary of D74116: [Sema][C++] Propagate conversion type in order to specialize the diagnostics.
Feb 6 2020, 3:36 AM · Restricted Project

Feb 5 2020

Anastasia accepted D73651: [OpenCL][CUDA][HIP][SYCL] Add norecurse.

LGTM! Thanks!

Feb 5 2020, 5:23 AM · Restricted Project

Feb 4 2020

Anastasia updated the diff for D73360: [OpenCL] Restrict address space conversions in nested pointers.

Add warning into IncompatiblePointerTypesDiscardsQualifiers group.

Feb 4 2020, 5:56 AM · Restricted Project
Anastasia added a comment to D73360: [OpenCL] Restrict address space conversions in nested pointers.

If it's reasonable to persist the failure kind, that would probably be good, but it might be a lot of work.

Feb 4 2020, 3:14 AM · Restricted Project