kpet added a comment. 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? > 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? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D68388/new/ https://reviews.llvm.org/D68388 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
