MIPS: Update the list of addr32 targets

gas/testsuite/

	* gas/mips/mips.exp: Add mipsisa32 and mipsisa32el to
	the list of addr32 targets.
Regression for i686 gdb.dwarf2/pieces-optimized-out.exp

Git 9a0dc9e3 regressed gdb.dwarf2/pieces-optimized-out.exp, visible on
i686 (the test doesn't run on x86_64):

 (gdb) p s
 -$1 = {a = 5, b = <optimized out>, c = <optimized out>, d = <optimized out>}
 +$1 = {a = 5, b = <optimized out>, c = 0, d = 0}
 -(gdb) PASS: gdb.dwarf2/pieces-optimized-out.exp: print s
 +(gdb) FAIL: gdb.dwarf2/pieces-optimized-out.exp: print s

The regression was caused by this removal in cp-valprint.c:

  @@ -293,12 +293,6 @@ cp_print_value_fields (struct type *type, struct type *real_type,
		  {
		    fputs_filtered (_("<synthetic pointer>"), stream);
		  }
  -             else if (!value_bits_valid (val,
  -                                         TYPE_FIELD_BITPOS (type, i),
  -                                         TYPE_FIELD_BITSIZE (type, i)))
  -               {
  -                 val_print_optimized_out (val, stream);
  -               }
		else
		  {
		    struct value_print_options opts = *options;

The idea was that we'd just fallback to calling value_field_bitfield,
which handles unavailable values (in unpack_value_bits_as_long_1) so
should be able to handle optimized out values too.  Alas, it doesn't.
This is currently a bit too messy.  Instead of teaching
unpack_value_bits_as_long_1 about optimized out bits, let's bite the
bullet and teach the value code to handle partially optimized out
bitfield, by having it unpack a bitfield and then propagate the range
metadata.  Turns out the resulting code looks simpler and clearer.

Tested on x86_64 Fedora 20, -m64/-m32.

gdb/ChangeLog:

	* value.c (value_ranges_copy_adjusted): New function, factored out
	from ...
	(value_contents_copy_raw): ... here.
	(unpack_value_bits_as_long_1): Rename back to ...
	(unpack_bits_as_long): ... this.  Remove 'original_value' and
	'result' parameters.  Change return type to LONGEST.
	(unpack_value_bits_as_long): Delete.
	(unpack_value_field_as_long_1): Delete.
	(unpack_value_field_as_long, unpack_field_as_long): Reimplement.
	(unpack_value_bitfield): New function.
	(value_field_bitfield): Reimplement using unpack_value_bitfield.
	(value_fetch_lazy): Use unpack_value_bitfield.
	* value.h (unpack_value_bits_as_long): Delete declaration.
Remove code to cope with LWPs wrapped as PIDs

Historically the Linux x86 watchpoint code did not cope with multi-
threaded processes and LWP IDs were passed to it wrapped as PIDs.
Not all entry points were converted when the Linux x86 watchpoint
code was made multi-thread-aware, so a handler was left in place to
cope with wrapped LWPs.  Since then all such entry points have been
converted to pass regular LWPs and the handler is now redundant.
This commit removes the handler and adds assertions to ensure no
wrapped LWPs are passed in future.

gdb/ChangeLog:

	* x86-linux-nat.c (x86_linux_dr_get, x86_linux_dr_set):
	Remove code to cope with LWPs wrapped as PIDs.
	Add assertions to ensure no wrapped LWPs are passed.
Fix PR fortran/17237: bug in f-valprint.c

This commit fixes the PR mentioned in $subject.  It is about a set but
unused variable that refers to the output format of integer values
printed in Fortran.

This was probably a thinko (like most set-but-unused-vars), but it
could cause an internal error depending on the scenario.  I am sending
a testcase which triggers this error as well.

gdb/ChangeLog:
2014-09-04  Sergio Durigan Junior  <sergiodj@redhat.com>

	PR fortran/17237
	* f-valprint.c (f_val_print): Specify the correct print option to
	use when printing integer values.

gdb/testsuite/ChangeLog:
2014-09-04  Sergio Durigan Junior  <sergiodj@redhat.com>

	PR fortran/17237
	* gdb.fortran/print-formatted.exp: New file.
	* gdb.fortran/print-formatted.f90: Likewise.
parse_number("0") reads uninitialized memory

valgrind caught that parse_number reads uninitialized memory when we
parse literal "0":

 $ valgrind ./gdb -q -nx -ex "set height 0"
 (...)
 ==10378== Conditional jump or move depends on uninitialised value(s)
 ==10378==    at 0x548A10: parse_number (c-exp.y:1828)
 ==10378==    by 0x54A340: lex_one_token (c-exp.y:2638)
 ==10378==    by 0x54B4BB: c_lex (c-exp.y:3089)
 ==10378==    by 0x544951: c_parse_internal (c-exp.c:2208)
 ==10378==    by 0x54BF8C: c_parse (c-exp.y:3260)
 ==10378==    by 0x6502E7: parse_exp_in_context_1 (parse.c:1221)
 ==10378==    by 0x650064: parse_exp_in_context (parse.c:1122)
 ==10378==    by 0x65001F: parse_exp_1 (parse.c:1114)
 ==10378==    by 0x650421: parse_expression (parse.c:1266)
 ==10378==    by 0x5A74B7: parse_and_eval_long (eval.c:92)
 ==10378==    by 0x501ABD: do_set_command (cli-setshow.c:302)
 ==10378==    by 0x721059: execute_command (top.c:452)
 ==10378==
 (gdb)

I've pushed the obvious fix.

Tested on x86_64 Fedora 20.

gdb/ChangeLog:
	* c-exp.y (parse_number): Skip handling base-switching prefixes if
	the input is only one character long.
daily update