chandlerc added a comment. So, doing research to understand the impact of this has convinced me we *really* need to stop doing this. Multiple libraries are actually trying to enumerate every CPU that has feature X for some feature X. =[[[ This, combined with the fundamental pattern of defining a precise macro for the CPU, leaves a time bomb where anyone that passes a new CPU to `-march` using some older headers will incorrectly believe features aren't available on *newer* CPUs. =[
Specific examples: https://github.com/hwoarang/glibc/blob/master/sysdeps/x86/cpu-features.h#L263 https://github.com/boostorg/atomic/blob/boost-1.65.1/include/boost/atomic/detail/caps_gcc_x86.hpp#L30 I think my conclusion is that the best way forward is to officially stop defining CPU-specific macros, but to also continue defining __corei7__ macros on all CPUs newer than that for all time so that old headers using these macros for "feature detection" actually work. Thoughts? ================ Comment at: lib/Basic/Targets/X86.cpp:835 defineCPUMacros(Builder, "slm"); + // gcc also defineds 'silvermont', but we never have. See comment below. break; ---------------- RKSimon wrote: > defines Nit picking detail: I would also capitalize GCC here and elsewhere. https://reviews.llvm.org/D38824 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
