================
@@ -659,13 +659,21 @@ llvm::ARM::FPUKind arm::getARMTargetFeatures(const Driver 
&D,
         CPUArgFPUKind != llvm::ARM::FK_INVALID ? CPUArgFPUKind : 
ArchArgFPUKind;
     (void)llvm::ARM::getFPUFeatures(FPUKind, Features);
   } else {
+    bool Generic = true;
     if (!ForAS) {
       std::string CPU = arm::getARMTargetCPU(CPUName, ArchName, Triple);
+      if (CPU != "generic")
+        Generic = false;
       llvm::ARM::ArchKind ArchKind =
           arm::getLLVMArchKindForARM(CPU, ArchName, Triple);
       FPUKind = llvm::ARM::getDefaultFPU(CPU, ArchKind);
       (void)llvm::ARM::getFPUFeatures(FPUKind, Features);
     }
+    if (Generic && (Triple.isOSWindows() || Triple.isOSDarwin()) &&
----------------
mstorsjo wrote:

So if the minimal fix in #134366 isn't really backportable, I'm not sure if I 
see many other reasonable ways to fix this breakage, so then we probably should 
revert this change for the 20.x branch. If we can land #130623 before 21.x (or 
at least the split out #134366) then both this and the armv7s/vfpv4 issue 
should be fixed for 21.x. And this PR in itself only attempted to fix things 
for downstream-patched Clang, so it's not strictly essential anyway.

https://github.com/llvm/llvm-project/pull/122095
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to