This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[PATCH] [SPARC] gas: fix bumping to architectures >v9 in sparc64-* targets.


Hi.  This patch fixes two related problems:
   
- By default gas is supposed to bump the current architecture (starting
  with v6) as it finds "higher" instructions as the assembling
  progresses.  There are four possible cases depending on the usage of
  the -A and -bump options:
    
  (a) No -A and -bump are specified.  In this case max_architecture must
      be the highest architecture not conflicting with the default
      architecture.  The default opcode architecture is indirectly set
      in configure.tgt and is "v9" in sparc64 systems (from "v9-64").
      Thus the maximum architecture in sparc64 systems must be "v9b".
      No warnings are echoed when the assembly of an instruction bumps
      the current architecture.
    
  (b) Only -bump is specified.  This is like (a) but warnings are always
      issued when the assembly of an instruction bumps the current
      architecture.
    
  (c) Only -A is specified.  In this case bumping to a new architecture
      is an error.
    
  (d) Both -A and -bump are specified.  In this case max_architecture
      must be the highest architecture not conflicting with the default
      architecture, but warnings are only to be issued when bumping to
      an architecture higher than the architecture selected in the -A
      option.
    
  `max_architecture' is a global variable defined in tc-sparc.c which is
   initialized to the opcode architecture corresponding to the default
   architecture ("sparclite" for sparc-* targets and "v9" for sparc64-*
   targets).  Then in `md_begin' it is set to the highest
   non-conflicting architecture, but only when both -A and -bump are
   specified.
    
   Thus (a) does not work:
    
      $ echo "fzero %f0" | as
      {standard input}: Assembler messages:
      {standard input}:1: Error: Architecture mismatch on "fzero".
      {standard input}:1:  (Requires v9a|v9b; requested architecture is v9.)
    
   Neither (b):
    
      $ echo "fzero %f0" | as -bump
      {standard input}: Assembler messages:
      {standard input}:1: Error: Architecture mismatch on "fzero".
      {standard input}:1:  (Requires v9a|v9b; requested architecture is v9.)
    
   Only (d) does:
    
      $ echo "fzero %f0" | as -Av9 -bump
      {standard input}: Assembler messages:
      {standard input}:1: Warning: architecture bumped from "v6" to "v9a" on "fzero"
    
   This patch fixes that function to "upgrade" `max_architecture' also
   in the (a) and (b) cases.
    
   Note that this problem becomes apparent only in sparc64-* targets
   because in sparc-* targets the default architecture is the "higher"
   among the 32bit architectures ("sparclite").
    
- Gas maintains a set of hardware capabilities associated with each gas
  architecture, in `sparc_arch_table'.  On the other hand libopcodes
  maintains a set of hardware capabilities needed by each individual
  sparc instruction.
    
  When an instruction is assembled in `sparc_ip' gas checks for the
  presence of the hardware capabilities required by the instruction,
  emitting an error if some capability is missing.
    
  However, this mechanism does not work properly if the current
  architecture is bumped due to an instruction requiring new hw
  capabilities not present on either the default architecture or an
  architecture specified with -A:
    
      $ echo "fzero %f0" | as -bump
      {standard input}: Assembler messages:
      {standard input}:1: Warning: architecture bumped from "v6" to "v9a" on "fzero"
      {standard input}:1: Error: Hardware capability "vis" not enabled for "fzero".
    
  This patch fixes this by adding the set of required hw caps of an
  instruction if it triggers an architecture bump.
    
Patch has been tested in sparc64-unknown-linux-gnu.
    
gas/Changelog:
  
   2014-09-03  Jose E. Marchesi  <jose.marchesi@oracle.com>
    
    	* config/tc-sparc.c (sparc_ip): Update the set of allowed hwcaps
    	when bumping the current architecture.
    	(md_begin): Adjust the highest architecture level also when a
    	specific architecture is not requested.


diff --git a/gas/config/tc-sparc.c b/gas/config/tc-sparc.c
index b5e9704..7497618 100644
--- a/gas/config/tc-sparc.c
+++ b/gas/config/tc-sparc.c
@@ -916,16 +916,24 @@ md_begin (void)
       /* `max_architecture' records the requested architecture.
 	 Issue warnings if we go above it.  */
       warn_after_architecture = max_architecture;
-
-      /* Find the highest architecture level that doesn't conflict with
-	 the requested one.  */
-      for (max_architecture = SPARC_OPCODE_ARCH_MAX;
-	   max_architecture > warn_after_architecture;
-	   --max_architecture)
-	if (! SPARC_OPCODE_CONFLICT_P (max_architecture,
-				       warn_after_architecture))
-	  break;
     }
+
+  /* Find the highest architecture level that doesn't conflict with
+     the requested one.  */
+
+  if (warn_on_bump
+      || !architecture_requested)
+  {
+    enum sparc_opcode_arch_val current_max_architecture
+      = max_architecture;
+
+    for (max_architecture = SPARC_OPCODE_ARCH_MAX;
+	 max_architecture > warn_after_architecture;
+	 --max_architecture)
+      if (! SPARC_OPCODE_CONFLICT_P (max_architecture,
+				     current_max_architecture))
+	break;
+  }
 }
 
 /* Called after all assembly has been done.  */
@@ -2963,6 +2971,7 @@ sparc_ip (char *str, const struct sparc_opcode **pinsn)
 		  warn_after_architecture = needed_architecture;
 		}
 	      current_architecture = needed_architecture;
+	      hwcap_allowed |= hwcaps;
 	    }
 	  /* Conflict.  */
 	  /* ??? This seems to be a bit fragile.  What if the next entry in


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]