Anastasia added a comment. In https://reviews.llvm.org/D28136#701508, @bader wrote:
> > From all the above arguments, I feel like the right approach would be to > > implement it as Clang builtin which closely matches the operator semantic > > in my opinion. We could of course reuse the implementation of > > __bultin_astype to avoid unnecessary extra work and code duplication. > > > > Using the macro seems to me more like a workaround solution and overloaded > > functions don't seem to be entirely the right thing either. What do you > > think about it? > > I don't think we need another Clang built-in. __builtin_astype was added > specifically for OpenCL needs (see rev. 132612). > Do you know better way to map astype operators (there are a lot of them > as_<type>#) to single Clang built-in? Unfortunately, __builtin_astype doesn't match the astype syntax from the spec exactly, which I wish it would. I don't feel strongly neither with macro (which messes up proper error reporting) nor with function declaration (for which implicit conversion would apply just like to other C functions). Having Clang builtin would feel the most natural way to me but I agree the way it is defined with the multiple distinct names for each type I am not going to advocate for it strongly. ================ Comment at: lib/Headers/opencl-c.h:6588 -char __ovld __cnfn as_char(char); -char __ovld __cnfn as_char(uchar); - ---------------- Why do we have some of the overloads omitted? Would this cause any extra conversions? uchar -> char in this case? https://reviews.llvm.org/D28136 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
