[Parallel_libs-commits] [PATCH] D23577: [StreamExecutor] Executor add synchronous methods

Jason Henline via Parallel_libs-commits parallel_libs-commits at lists.llvm.org
Wed Aug 24 12:06:55 PDT 2016


Not sure what the protocol is for finding issues in patches that have
already been committed - should I be posting to parallel_libs-dev instead?

I think either place is a good choice for this kind of issue. Thanks for
finding this. I'll get a fix in today and add some unit tests to make sure
it is working :).

On Wed, Aug 24, 2016 at 11:56 AM James Price <j.price at bristol.ac.uk> wrote:

> jprice added a comment.
>
> Not sure what the protocol is for finding issues in patches that have
> already been committed - should I be posting to parallel_libs-dev instead?
>
> This issue only showed up when I tried to actually write some code that
> uses all this stuff.
>
>
> ================
> Comment at:
> parallel-libs/trunk/streamexecutor/include/streamexecutor/Executor.h:44
> @@ +43,3 @@
> +  Expected<GlobalDeviceMemory<T>> allocateDeviceMemory(size_t
> ElementCount) {
> +    return PExecutor->allocateDeviceMemory(ElementCount * sizeof(T));
> +  }
> ----------------
> There's a mismatch between the return types of these two
> `allocateDeviceMemory` methods. The `PlatformExecutor` version returns a
> `GlobalDeviceMemoryBase`, whereas this one tries to return a
> `GlobalDeviceMemory<T>`.
>
> This causes compilation failure if this
> `Executor::allocateDeviceMemory<T>()` method is actually used. Because this
> method is templated, it needs to actually be called somewhere for the issue
> to show up, and it doesn't appear to be covered in the unit tests.
>
>
>
> Repository:
>   rL LLVM
>
> https://reviews.llvm.org/D23577
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/parallel_libs-commits/attachments/20160824/78207451/attachment.html>


More information about the Parallel_libs-commits mailing list