Hahnfeld added a comment. In https://reviews.llvm.org/D47849#1184367, @hfinkel wrote:
> The problem is that the inline assembly might actually be for the target, > instead of the host, because we also have target preprocessor macros defined, > and it's going to be hard to tell. I'm not sure that there's a great solution > here, and I agree that having something more general than undefining some > specific things that happen to matter for math.h would be better. As you > point out, this is not just a system-header problem. We might indeed want to > undefine all of the target-feature-related macros (although that won't always > be sufficient, because we need basic arch macros for the system headers to > work at all, and those are generally enough to guard some inline asm). I think there was a reason for pulling in the host defines. I'd have to look at the commit message though... > Maybe the following makes sense: Only define the host macros, minus > target-feature ones, when compiling for the target in the context of the > system headers. That makes the system headers work while providing a "clean" > preprocessor environment for the rest of the code (and, thus, retains our > ability to complain about bad inline asm). I'm not sure how that's going to help with Eigen: Just including `Eigen/Core` will pull in the other header file I mentioned with inline assembly. That's completely independent of preprocessor macros, I think it's enough the library's build system detected the host architecture during install. Repository: rC Clang https://reviews.llvm.org/D47849 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
