gdb and binutils branch master updated. 75ac3a7f57ee93e9c59ca6e446ad14f860b9e7e5

[jemarch at sourceware dot org]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "gdb and binutils".

The branch, master has been updated
       via  75ac3a7f57ee93e9c59ca6e446ad14f860b9e7e5 (commit)
      from  a9d58c068ccfa66fd94fffc001bbaf996ec53a7d (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=75ac3a7f57ee93e9c59ca6e446ad14f860b9e7e5

commit 75ac3a7f57ee93e9c59ca6e446ad14f860b9e7e5
Author: Jose E. Marchesi <jemarch@gnu.org>
Date:   Fri Sep 12 15:38:21 2014 +0200

    gas: fix bumping to architectures >v9 in sparc64-* targets.
    
    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.
    
    The patch has been tested in sparc64-unknown-linux-gnu.
    
    gas/ChangeLog:
    
    2014-09-12  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 highetst architecture level also when a
    	specific architecture is not requested.

-----------------------------------------------------------------------

Summary of changes:
 gas/ChangeLog         |    7 +++++++
 gas/config/tc-sparc.c |   27 ++++++++++++++++++---------
 2 files changed, 25 insertions(+), 9 deletions(-)


hooks/post-receive
-- 
gdb and binutils