From 6028a6921a2c96a3e2c8e8c4cf27982bf256e304 Mon Sep 17 00:00:00 2001
From: Jeffrey Walton <noloader@gmail.com>
Date: Fri, 30 Nov 2018 09:12:35 -0500
Subject: [PATCH] Fix SIGILL in TestDARN() function I thought this was due to
 trying to call the darn instruction even though g_hasDARN == false on Power8.
 However, the problem turned out to be a Power9 load was used when DARN class
 threw a DARN_Err.

---
 GNUmakefile    | 2 +-
 ppc_power9.cpp | 8 --------
 2 files changed, 1 insertion(+), 9 deletions(-)

diff --git a/GNUmakefile b/GNUmakefile
index 50d3624c..b07a7917 100755
--- a/GNUmakefile
+++ b/GNUmakefile
@@ -637,7 +637,7 @@ ifeq ($(DETECT_FEATURES),1)
   TOPT = $(POWER9_FLAG)
   HAVE_OPT = $(shell $(CXX) $(TCXXFLAGS) $(ZOPT) $(TOPT) $(TPROG) -o $(TOUT) 2>&1 | tr ' ' '\n' | wc -l)
   ifeq ($(strip $(HAVE_OPT)),0)
-    DARN_FLAG = $(POWER9_FLAG)
+    # DARN_FLAG = $(POWER9_FLAG)
   else
     POWER9_FLAG =
   endif
diff --git a/ppc_power9.cpp b/ppc_power9.cpp
index 02d08588..c842d46d 100644
--- a/ppc_power9.cpp
+++ b/ppc_power9.cpp
@@ -6,14 +6,6 @@
 //    additional CXXFLAGS are required to enable the appropriate
 //    instructions sets in some build configurations.
 
-// The XLC on Linux case is a special case because code generated by XLC on
-// Linux claims the generator is available when it is not. LLVM Clang does
-// not have the trouble. The problem seems to be related to the signal
-// handler. It looks like first call to CPU_ProbePower9() and CPU_ProbeDARN()
-// are correct, but the call to HasDARN() returns the wrong result. If I am
-// parsing things correctly while stepping the code and disassembly, it looks
-// like the result of the inline asm is being removed.
-
 #include "pch.h"
 #include "config.h"