[PATCH] D68388: [PR41008][OpenCL] Add OpenCL C compatibility mode to C++ for OpenCL

[Anastasia Stulova via Phabricator via cfe-commits]

Anastasia added a comment.

In D68388#1756701 <https://reviews.llvm.org/D68388#1756701>, @kpet wrote:

> Thanks for the feedback.
>
> > I think we should use -fpermissive rather than adding similar flag to Clang.
>
> Could you point me at a use of `-fpermissive` for a similar case? Also it seems `-fpermissive` is not mentioned in the Clang manual or the help text. Am I missing something?




  bin/clang -fpermissive test.cl

Clang already has the flag added. So you can just start using it I presume. Feel free to document it.

> 
> 
>> At the end we might end up with other cases where we need similar mechanism it doesn't make sense to add a flag for each case.
> 
> Completely agree and that was one of the reasons I decided to add a generic flag like this. I felt that compatibility with existing OpenCL C source was an important enough use-case to warrant adding a flag for it especially since, as you say, we expect such a flag could be useful to control several bits of behaviour.
> 
>> Also I am not sure that what you are doing here is really enabling OpenCL C compatibility mode that would imply to me that restrict is expected to behave in C++ mode as it was in C but is it really the case?
> 
> Isn't restrict mainly an optimisation feature? That's certainly my reading of 6.7.3-7 in the C99 spec:
> 
>> The intended use of the restrict qualifier (like the register storage class) is to promote
>> optimization, and deleting all instances of the qualifier from all preprocessing translation
>> units composing a conforming program does not change its meaning (i.e., observable
>> behavior).
> 
> The main goal here is to be able to consume existing OpenCL C source without modifications. I thought that enabling existing behaviour for `restrict`/`__restrict` that may result in additional optimisations was more useful than just discarding `restrict`, which would be a valid way of achieving compatibility. Is there something specific that worries you?

C++ deviates from C so restrict in C++ might not be restrict in C. Can we confidently say we will support restrict exactly like OpenCL C does i.e. C99?

In other words I believe it is much safe to say that we support `restrict` in adhoc way that deviates C++ for OpenCL documentation without implying developers should refer to OpenCL C and C99 spec to get how it works. We can also use this mechanism for any behavior that deviates the documentation rather than adding a flag for each (i.e. we might want to deviate in something that doesn't come from OpenCL C at all).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D68388/new/

https://reviews.llvm.org/D68388