Don't set CC in config/i386/go32.mh

I cross-compile gdb for msdosdjgpp (both target and host is
i586-pc-msdosdjgpp), so the CC should be i586-pc-msdosdjgpp-gcc.
However, CC is set incorrectly to gcc after config/i386/go32.mh is inlined
into the Makefile.

This patch is to remove the CC setting in config/i386/go32.mh.

gdb:

2014-11-19  Yao Qi  <yao@codesourcery.com>

	* config/i386/go32.mh (CC): Remove.
varsize-limit error printing element of packed array...

... when that packed array is part of a discriminated record and
one of the bounds is a discriminant.

Consider the following code:

   type FUNNY_CHAR_T is (NUL, ' ', '"', '#', [etc]);
   type FUNNY_STR_T is array (POSITIVE range <>) of FUNNY_CHAR_T;
   pragma PACK (FUNNY_STR_T);
   type FUNNY_STRING_T (SIZE : NATURAL := 1) is
      record
         STR    : FUNNY_STR_T (1 .. SIZE) := (others => '0');
         LENGTH : NATURAL := 4;
      end record;
   TEST: FUNNY_STRING_T(100);

GDB is able to print the value of variable "test" and "test.str".
But not "test.str(1)":

    (gdb) p test
    $1 = (size => 100, str => (33 'A', nul <repeats 99 times>), length => 1)
    (gdb) p test.str
    $2 = (33 'A', nul <repeats 99 times>)
    (gdb) p test.str(1)
    object size is larger than varsize-limit

The problem occurs during the phase where we are trying to resolve
the expression subscript operation. On the one hand of the subscript
operator, we have the result of the evaluation of "test.str", which
is our packed array. We have the following code to handle packed
arrays in particular:

      if (ada_is_constrained_packed_array_type
          (desc_base_type (value_type (argvec[0]))))
        argvec[0] = ada_coerce_to_simple_array (argvec[0]);

This eventually leads to a call to constrained_packed_array_type
to return the "simple array".  This function relies on a parallel
___XA type, when available, to determine the bounds.  In our case,
we find type...

    failure__funny_string_t__T4b___XA"

... which has one field describing the bounds of our array as:

    failure__funny_string_t__T3b___XDLU_1__size

The part that interests us is after the ___XD suffix or,
in other words: "LU_1__size". What this means in GNAT encoding
parlance is that the lower bound is 1, and that the upper bound
is the value of "size". "size" is our discriminant in this case.

Normally, we would access the record's discriminant in order to
get the upper bound's value, but we do not have that information,
here. We are in a mode where we are just trying to "fix" the type
without an actual value. This is what the call to to_fixed_range_type
is doing, and because the fix'ing fails, it ends up returning
the ___XDLU type unmodified as our index type.

This shouldn't be a problem, except that the later part of
constrained_packed_array_type then uses that index_type to
determine the array size, via a call to get_discrete_bounds.
The problem is that the upper bound of the ___XDLU type is
dynamic (in the DWARF sense) while get_discrete_bounds implicitly
assumes that the bounds are static, and therefore accesses
them using macros that assume the bounds values are constants:

    case TYPE_CODE_RANGE:
      *lowp = TYPE_LOW_BOUND (type);
      *highp = TYPE_HIGH_BOUND (type);

This therefore returns a bogus value for the upper bound,
leading to an unexpectedly large size for our array, which
later triggers the varsize-limit guard we've seen above.

This patch avoids the problem by adding special handling
of dynamic range types. It also extends the documentation
of the constrained_packed_array_type function to document
what happens in this situation.

gdb/ChangeLog:

        * ada-lang.c (constrained_packed_array_type): Set the length
        of the return array as if both bounds where zero if that
        returned array's index type is dynamic.

gdb/testsuite/ChangeLog:

        * gdb.ada/pkd_arr_elem: New Testcase.

Tested on x86_64-linux.
[Ada] Ignore __XA types when redundant.

Consider the following code which declares a variable A2 which
is an array of arrays of integers.

   type Array2_First is array (24 .. 26) of Integer;
   type Array2_Second is array (1 .. 2) of Array2_First;
   A1 : Array1_Second := ((10, 11, 12), (13, 14, 15));

Trying to print the type of that variable currently yields:

    (gdb) ptype A2
    type = array (1 .. 2, 24 .. 26) of integer

This is not correct, as this is the description of a two-dimension
array, which is different from an array of arrays. The expected
output is:

    (gdb) ptype a2
    type = array (1 .. 2) of foo_n926_029.array2_first

GDB's struct type currently handles multi-dimension arrays the same
way arrays of arrays, where each dimension is stored as a sub-array.
The ada-valprint module considers that consecutive array layers
are in fact multi-dimension arrays. For array of arrays, a typedef
layer is introduced between the two arrays, creating a break between
each array type.

In our situation, A2 is a described as a typedef of an array type...

        .uleb128 0x8    # (DIE (0x125) DW_TAG_variable)
        .ascii "a2\0"   # DW_AT_name
        .long   0xfc    # DW_AT_type

        .uleb128 0x4    # (DIE (0xfc) DW_TAG_typedef)
        .long   .LASF5  # DW_AT_name: "foo__array2_second"
        .long   0x107   # DW_AT_type

        .uleb128 0x5    # (DIE (0x107) DW_TAG_array_type)
        .long   .LASF5  # DW_AT_name: "foo__array2_second"
        .long   0xb4    # DW_AT_type
        .uleb128 0x6    # (DIE (0x114) DW_TAG_subrange_type)
        .long   0x11b   # DW_AT_type
        .byte   0x2     # DW_AT_upper_bound
        .byte   0       # end of children of DIE 0x107

... whose element type is, as expected, a typedef to the sub-array
type:

        .uleb128 0x4    # (DIE (0xb4) DW_TAG_typedef)
        .long   .LASF4  # DW_AT_name: "foo__array2_first"
        .long   0xbf    # DW_AT_type

        .uleb128 0x9    # (DIE (0xbf) DW_TAG_array_type)
        .long   .LASF4  # DW_AT_name: "foo__array2_first"
        .long   0xd8    # DW_AT_GNAT_descriptive_type
        .long   0x1c5   # DW_AT_type
        .uleb128 0xa    # (DIE (0xd0) DW_TAG_subrange_type)
        .long   0xf0    # DW_AT_type
        .byte   0x18    # DW_AT_lower_bound
        .byte   0x1a    # DW_AT_upper_bound
        .byte   0       # end of children of DIE 0xbf

The reason why things fails is that, during expression evaluation,
GDB tries to "fix" A1's type. Because the sub-array has a parallel
(descriptive) type (DIE 0xd8), GDB thinks that our array's index
type must be dynamic and therefore needs to be fixed. This in turn
causes the sub-array to be "fixed", which itself results in the
typedef layer to be stripped.

However, looking closer at the parallel type, we see...

        .uleb128 0xb    # (DIE (0xd8) DW_TAG_structure_type)
        .long   .LASF8  # DW_AT_name: "foo__array2_first___XA"
        [...]
        .uleb128 0xc    # (DIE (0xe4) DW_TAG_member)
        .long   .LASF10 # DW_AT_name: "foo__Tarray2_firstD1___XDLU_24__26"

... that all it tells us is that the array bounds are 24 and 26,
which is already correctly provided by the array's DW_TAG_subrange_type
bounds, meaning that this parallel type is just redundant.

Parallel types in general are slowly being removed in favor of
standard DWARF constructs. But in the meantime, this patch kills
two birds with one stone:

  1. It recognizes this situation where the XA type is useless,
     and saves an unnecessary range-type fixing;

  2. It fixes the issue at hand because ignoring the XA type results
     in no type fixing being required, which allows the typedef layer
     to be preserved.

gdb/ChangeLog:

        * ada-lang.c (ada_is_redundant_range_encoding): New function.
        (ada_is_redundant_index_type_desc): New function.
        (to_fixed_array_type): Ignore parallel XA type if redundant.

gdb/testsuite/ChangeLog:

        * gdb.ada/arr_arr: New testcase.

Tested on x86_64-linux.
[Ada] gdb.ada/complete.exp failure on x86_64-windows

Using the example in gdb.ada/complete.exp, the following command
on x86_64-windows returns one unwanted completion choice :

    (gdb) complete p pck
    p <pck_E>>
    [all following completions entries snipped, all expected]

I tracked down this suprising entry to a minimal symbol whose name
is ".refptr.pck_E". The problem occurs while trying to see if
this symbol matches "pck" when doing wild-matching as we are doing
here:

  /* Second: Try wild matching...  */

  if (!match && wild_match_p)
    {
      /* Since we are doing wild matching, this means that TEXT
         may represent an unqualified symbol name.  We therefore must
         also compare TEXT against the unqualified name of the symbol.  */
      sym_name = ada_unqualified_name (ada_decode (sym_name));
      if (strncmp (sym_name, text, text_len) == 0)
        match = 1;
    }

What happens is that ada_decode correctly identifies the fact that
SYM_NAME (".refptr.pck_E") is not following any GNAT encoding, and
therefore returns that same name, but bracketed: "<.refptr.pck_E>".
This is the convention we use for telling GDB that the decoded name
is not a real Ada name - and therefore should not be encoded for
operations such as name matching, symbol lookups, etc. So far, so good.

Next is the call to ada_unqualified_name, which unfortunately does
not notice that the decoded name it is being given isn't a natural
symbol, and just blindly strips everything up to the last do, returning
"pck_E>". And of course, "pck_E>" matches "pck" now, and so we end
up accepting this symbol as a match.

This patch fixes the problem by making ada_unqualified_name a little
smarter by making sure that the given decoded symbol name does not
start with '<'.

gdb/ChangeLog:

        * ada-lang.c (ada_unqualified_name): Return DECODED_NAME if
        it starts with '<'.

Tested on x86_64-windows using AdaCore's testsuite as well as
on x86_64-linux.
Use 2-byte instead of 4-byte NOP on S390 in 'bp-permanent' test case

The bp-permanent test case assumes that a NOP is exactly as long as a
software breakpoint.  This is not the case for the S390 "nop"
instruction, which is 4 bytes long, while a software breakpoint is
just 2 bytes long.  The "nopr" instruction has the right size and can
be used instead.

Without this patch the test case fails on S390 when trying to continue
after SIGTRAP on the permanent breakpoint:

  ...
  Continuing.

  Program received signal SIGILL, Illegal instruction.
  test () at /home/arnez/src/binutils-gdb/gdb/testsuite/gdb.base/bp-permanent.c:40
  40	  NOP; /* after permanent bp */
  (gdb)
  FAIL: gdb.base/bp-permanent.exp: always_inserted=off, sw_watchpoint=0:
    basics: stop at permanent breakpoint

With this patch the test case succeeds without any FAILs.

gdb/testsuite/ChangeLog:

	* gdb.base/bp-permanent.c (NOP): Define as 2-byte instead of
	4-byte instruction on S390.
[AArch64] Warn on load pair to same register

  2014-11-19  Ryan Mansfield  <rmansfield@qnx.com>

    * config/tc-aarch64.c (md_assemble): Call warn_unpredictable_ldst.
    (warn_unpredictable_ldst): New.

  2014-11-19  Ryan Mansfield <rmansfield@qnx.com>

    * gas/aarch64/diagnostic.s: Add new warnings test patterns.
    * gas/aarch64/diagnostic.l: Update expected diagnostic output.
Fix signedness warning

This is the updated version using uintptr_t as Alan Modra suggested.

2014-11-18  Jan-Benedict Glaw  <jbglaw@lug-owl.de>

	* dwarf.c (process_extended_line_op): Fix signedness warning.
Fix date in ChangeLog entry
Default powerpc64 to --plt-thread-safe for Go

Go is multi-threaded, so use thread-safe plt stubs.  __go_go doesn't
actually start threads, but is a convenient libgo function with a
reasonably unique name that is called by all Go executables.  (Threads
are started by a static function of libgo, runtime_newosproc, called
by a whole lot of global functions, including runtime_starttheworld
and runtime_main.)

bfd/
	* elf64-ppc.c (ppc64_elf_size_stubs): Add __go_go to thread_starters.
gold/
	* powerpc.cc (Target_powerpc::do_relax): Add __go_go to thread_starters.
Automatic date update in version.in