[PATCH] D27334: [OpenCL] Ambiguous function call.

[Richard Smith via cfe-commits]

On 5 Dec 2016 9:42 am, "Anastasia Stulova via Phabricator via cfe-commits" <
cfe-commits at lists.llvm.org> wrote:

Anastasia added a comment.

In https://reviews.llvm.org/D27334#612858, @bader wrote:

> In https://reviews.llvm.org/D27334#611703, @Anastasia wrote:
>
> > This change seems to modify normal C behavior again. Is there any
strong motivation for doing this and if yes could it be done generically
with C?
>
>
> Motivation:
>
>   // Non-portable OpenCL 1.2 code
>   __kernel void foo(global float* out) {
>     out[get_global_id(0)] = sin(get_global_id(0));
>   }
>
>
> This program compiles fine on OpenCL platform w/o doubles support


Perhaps that is the problem (that there are two modes that do different
things)? Could we make the double overload be present but unselectable to
diagnose this problem in that mode too?

and fails otherwise.
>  If OpenCL driver supports doubles it provides at least two versions of
'sin' built-in math function and compiler will not be able to choose the
right one for 'size_t' argument.


Do you have a real example? If someone passes an integer to 'sin', I think
there's a better warning we can give them :)

>  The goal of this warning is to let OpenCL developer know about potential
issues with code portability.


I would argue this improves the portability much as it can also be
misleading in some situations (because it refers to a potentially
hypothetical problem). For example there can be builtin functions that only
have a float parameter (without a double version of it). This is for
example the case with read_image functions that take a float coordinate
value between 0 and 1. Unfortunately this warning won't be triggered on
read_image functions because there is an overload candidate with an int
type of the same parameter too. But we can't exclude this situations to
appear in the future or from some vendor extensions or even custom OpenCL
code.


https://reviews.llvm.org/D27334



_______________________________________________
cfe-commits mailing list
cfe-commits at lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20161205/ea1c5c65/attachment.html>