Hahnfeld added a comment. In https://reviews.llvm.org/D50845#1204210, @ABataev wrote:
> > 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. > > Again, it does not matter how common is this situation. We cannot rely on the > probability here, we need to make the compiler to work correctly in all > possible situation, no matter how often they can occur. Got that, I agree on the conservative approach: If we find a function to be called that wasn't checked (because it wasn't implicitly `declare target` on the host) the compiler can error out. That should be correct in all cases, shouldn't it? There's a trade-off here: - How many TUs pass full analysis and how many don't? (today's situation; we know that some headers don't work) - How many TUs pass when we only check called functions (and error if we call non-checked ones) and how many regress compared to today's situation? If the number of regressions is zero for all practical situations but we can compile some important cases, that should be a win. >>>>> 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? > > Just like as usual - if the assembler is supported by the device - it is ok, > otherwise - error message. Even if the function is never called? That would mean you can't include any `Eigen` header... 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
