This patch reworks the fix to avoid a compile time warning so that it will work
with later versions of gcc.

	PR ld/16821
	* peXXigen.c (_bfd_XXi_swap_sym_out): Rework fix to avoid compile
	time warning.
[gdbserver] Correctly generate i386-avx512.c

The makefile rule i386-avx512.c is to generate i386-avx512.c, but it
is written to i386-avx.c by mistake.  This patch is to fix this typo.

gdb/gdbserver:

2014-04-28  Yao Qi  <yao@codesourcery.com>

	* Makefile.in (i386-avx512.c): Fix the typo of generated file
	name.
This fixes a bootstrapping problem with gcc 4.9 in an x86 PE environment.
The problem was that references to weak function symbols were being
incorrectly biased by definition's offset.

	PR gas/16858
	* config/tc-i386.c (md_apply_fix): Do not adjust value of
	pc-relative fixes against weak symbols.
remove unnecessary second call to static_unwrap_type in ada_evaluate_subexp

In ada-lang.c::ada_evaluate_subexp, case OP_VAR_VALUE, when noside
is EVAL_AVOID_SIDE_EFFECTS, the first thing we do is set type as
follow:

    type = static_unwrap_type (SYMBOL_TYPE (exp->elts[pc + 2].symbol));

Later on in the same block, we make the same call:

    return value_zero
      (to_static_fixed_type
       (static_unwrap_type (SYMBOL_TYPE (exp->elts[pc + 2].symbol))),
       not_lval);

This patch removes the second call, since it should result in the same
type being returned, so no point in making that call again.

gdb/ChangeLog:

        * ada-lang.c (ada_evaluate_subexp) <OP_VAR_VALUE>: Remove
        unnecessary second call to static_unwrap_type.
Unnecessary XA type handling in ada_varobj_describe_simple_array_child

ada-varobj.c::ada_varobj_describe_simple_array_child only ever gets
called after all GNAT encodings have been applied to (parent_value,
parent_type). So there is no point in redoing it partially by
checking for parallel XA types again.

gdb/ChangeLog:

	* ada-varobj.c (ada_varobj_describe_simple_array_child): Remove
	handling of parallel ___XA types.
Enhance dwarfread.c::resolve_dynamic_type to resolve dynamic ranges

This change breaks down the resolve_dynamic_bounds function which
works only on arrays and its index range types into two functions,
one that resolves range types, and one that resolves arrays (using
the new routine to resolve the array's index range type). The
is_dynamic_type and resolve_dynamic_type function are then re-organized
to handle range types as well.

One small change worth mentioning is the fact that, now that range
types are resolved on their own (rather than in the limited context
of array index types), the resolved range types are created from
a copy of the dynamic range type, rather than from scratch (first
parameter of create_range_type). This allows us to preserve as many
original properties in the resolved type as possible (Eg. the type's
name).

This is preparation work that will help better support dynamic range
types for languages that allow the declaration of such types (Eg. Ada).

gdb/ChangeLog:

        * dwarf2read.c (is_dynamic_type): Return true for dynamic
        range types.  Adjust the array handling implementation to
        take advantage of this change.
        (resolve_dynamic_range): New function, mostly extracted from
        resolve_dynamic_bounds.
        (resolve_dynamic_array): New function, mostly extracted from
        resolve_dynamic_bounds.
        (resolve_dynamic_bounds): Delete.
        (resolve_dynamic_type): Reimplement.  Add handling of
        TYPE_CODE_RANGE types.
Improve Ada dynamic range type handling.

Consider the following declaration in Ada...

   type Array_Type is array (L .. U) of Natural;

... where L and U are parameters of the function where the declaration
above was made. At the moment, GDB relies on descriptive types in order
to properly decode the array bounds. For instance, if L was 5, and U
was 10, we would see the following:

    (gdb) ptype array_type
    type = array (5 .. 10) of natural
    (gdb) maintenance set ada ignore-descriptive-types
    (gdb) ptype array_type
    type = array (1 .. 28544912) of natural

This patch enhances ada_discrete_type_{high,low}_bound to resolve
any dynamicity.  This is sufficient to fix the case of the upper bound.
For the lower bound, the dwarf2read module does not handle dynamic
lower bounds yet, but once it does, the lower bound should be correctly
handled as well [1].

gdb/ChangeLog:

        * ada-lang.c (ada_discrete_type_high_bound): Resolve the type's
        dynamic bounds before computing its upper bound.
        (ada_discrete_type_low_bound): Same as above with the lower bound.

[1]: The reason why we do not enhance dwarf2read to handle dynamic
lower bounds ahead of this patch is because it unveils some latent
issues such as this one.
dwarf2read.c::read_subrange_type: Handle dynamic lower bounds

Currently, read_subrange_type handles dynamicity only in the case of
the upper bound, and assumes that the lower bound is always static.
That's rooted in the fact that dynamicity was added to support C99
variable-length arrays, where the lower bound is always zero, and
therefore never dynamic.  But the lower bound can, in fact, be dynamic
in other languages such as Ada.

Consider for instance the following declaration in Ada...

    type Array_Type is array (L .. U) of Natural;

... where L and U are parameters of the function where the declaration
above was made, and whose value are 5 and 10.  Currently, the debugger
is able to print the value of the upper bound correctly, but not the
lower bound:

    (gdb) ptype array_type
    type = array (1 .. 10) of natural

After this patch, the debugger now prints:

    (gdb) ptype array_type
    type = array (5 .. 10) of natural

gdb/ChangeLog:

        * dwarf2read.c (read_subrange_type): Handle dynamic
        DW_AT_lower_bound attributes.
Add gdb.ada/dyn_arrayidx testcase.

This add a testcases that verifies correct handling of dynamicity
for lower bounds of arrays.

gdb/testsuite/ChangeLog:

        * gdb.ada/dyn_arrayidx: New testcase.
daily update