Fix for DARN opcode error during ppc64le compilation of rng-tools which
occurs with binutils 2.38 but not with binutils 2.37..

https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=cebc89b9328;hp=9cbed90ee623d75e31994e7943960c997ba565f2


diff -aur a/gas/config/tc-ppc.c b/gas/config/tc-ppc.c
--- a/gas/config/tc-ppc.c
+++ b/gas/config/tc-ppc.c
@@ -5965,7 +5965,30 @@
 	     options do not count as a new machine, instead they add
 	     to currently selected opcodes.  */
 	  ppc_cpu_t machine_sticky = 0;
-	  new_cpu = ppc_parse_cpu (ppc_cpu, &machine_sticky, cpu_string);
+	  /* Unfortunately, some versions of gcc emit a .machine
+	     directive very near the start of the compiler's assembly
+	     output file.  This is bad because it overrides user -Wa
+	     cpu selection.  Worse, there are versions of gcc that
+	     emit the *wrong* cpu, not even respecting the -mcpu given
+	     to gcc.  See gcc pr101393.  And to compound the problem,
+	     as of 20220222 gcc doesn't pass the correct cpu option to
+	     gas on the command line.  See gcc pr59828.  Hack around
+	     this by keeping sticky options for an early .machine.  */
+	  asection *sec;
+	  for (sec = stdoutput->sections; sec != NULL; sec = sec->next)
+	    {
+	      segment_info_type *info = seg_info (sec);
+	      /* Are the frags for this section perturbed from their
+	         initial state?  Even .align will count here.  */
+	      if (info != NULL
+	          && (info->frchainP->frch_root != info->frchainP->frch_last
+	              || info->frchainP->frch_root->fr_type != rs_fill
+	              || info->frchainP->frch_root->fr_fix != 0))
+	        break;
+	    }
+	  new_cpu = ppc_parse_cpu (ppc_cpu,
+	                           sec == NULL ? &sticky : &machine_sticky,
+	                           cpu_string);
 	  if (new_cpu != 0)
 	    ppc_cpu = new_cpu;
 	  else