craig.topper added a comment. I think the only error we have for X86 is trying to use a -march for a cpu that only supports 32 bit but compiling 64 bit code.
I dont' think we can error for -mcx16 on a 32-bit target. For -march=native, the driver will call getHostCPUFeatures and get a list of features. As far as I can tell CPUID will report cx16 is supported even in 32-bit mode if the host CPU supports it in 64-bit mode. The driver will pass the list of features returned by getHostCPUFeatures onto the command line of the cc1 invocation. Those command line options will then be fed to initFeatureMap/setFeatureEnabled. We don't have the information to distinquish that from the user passing -mcx16. -mcx16 is intercepted by the driver and passed to cc1 in a similar way. I don't think we can filter cx16 from getHostCPUFeatures in 32-bit mode since the host might be running in 32-bit mode, but we could be passing -m64 to the compiler. So I don't think getHostCPUFeatures can look at the current operating mode of the CPU. I guess we could error for -mcx16 in the driver itself. But due to march native we'd still have to protect the code in cc1. Unless we also had the driver filter the output of getHostCPUFeatures before passing to cc1. Which if we did that then we probably could error from initFeatureMap/setFeatureEnabled. But gcc doesn't error for any use of cx16 in 32-bit mode so might be bad for compatibility anyway? Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D59287/new/ https://reviews.llvm.org/D59287 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
