Hahnfeld added a comment. In https://reviews.llvm.org/D50845#1203991, @ABataev wrote:
> In https://reviews.llvm.org/D50845#1203973, @Hahnfeld wrote: > > > In https://reviews.llvm.org/D50845#1203967, @ABataev wrote: > > > > > I thought about this approach already. But it won't work in general. The > > > main problem here is that host and device compilation phases may end up > > > with the different set of implicit declare target functions. The main > > > problem here not the user code, but the system libraries, which may use > > > the different set of functions. > > > > > > How common is that for functions that are used in `target` regions? In the > > worst case we can make my fourth point a warning and lose Sema checking for > > those functions. > > > It does not matter how common is it or not. If the bad situation can happen, > it will happen. > Warning won't work here, because, again, you may end up with the code that > may cause compiler crash for the device. For example, if the system function > uses throw/catch stmts, we may emit the warning for this function, but will > have troubles during the codegen. Right, warning wasn't a good thought. We really want strict checking and would have to error out when we find a function that wasn't implicitly `declare target` on the host. I meant to ask how common that would be? If that's only some known functions we could handle them separately. >>> The best solution is to use only device specific header files. Device >>> compilation phase should use system header files for the host at all. >> >> You mean "shouldn't use system header files for the host"? I think that may >> be hard to achieve, especially if we want to Sema check all of the source >> code during device compilation. > > Yes, I mean should not. Yes, this is hard to achieve but that's the only > complete and correct solution. Everything else looks like a non-stable hack. How do you propose to handle inline assembly in non-system header files? Repository: rC Clang https://reviews.llvm.org/D50845 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
