In https://sourceware.org/ml/gdb-patches/2017-12/msg00215.html, Jan
pointed out that the scalar printing patches caused a regression in
scm-ports.exp on x86.
What happens is that on x86, this:
	set sp_reg [get_integer_valueof "\$sp" 0]
... ends up setting sp_reg to a negative value, because
get_integer_valueof uses "print/d":
    print /d $sp
    $1 = -11496
Then later the test suite does:
    gdb_test "guile (print (seek rw-mem-port (value->integer sp-reg) SEEK_SET))" \
	"= $sp_reg" \
	"seek to \$sp"
... expecting this value to be identical to the saved $sp_reg value.
However it gets:
    guile (print (seek rw-mem-port (value->integer sp-reg) SEEK_SET))
    = 
4294955800
"print" is just a wrapper for guile's format:
    gdb_test_no_output "guile (define (print x) (format #t \"= ~A\" x) (newline))"
The seek function returns a scm_t_off, the printing of which is
handled by guile, not by gdb.
Tested on x86-64 Fedora 26 using an ordinary build and also a -m32
build.
2018-01-15  Tom Tromey  <tom@tromey.com>
	* gdb.guile/scm-ports.exp (test_mem_port_rw): Use get_valueof to
	compute sp_reg.
 
+2018-01-15  Tom Tromey  <tom@tromey.com>
+
+       * gdb.guile/scm-ports.exp (test_mem_port_rw): Use get_valueof to
+       compute sp_reg.
+
 2018-01-12  Andrew Burgess  <andrew.burgess@embecosm.com>
 
        * gdb.base/whatis-ptype-typedefs.exp: Don't run tests if we failed
 
            "get sp reg"
        # Note: Only use $sp_reg for gdb_test result matching, don't use it in
        # gdb commands.  Otherwise transcript.N becomes unusable.
-       set sp_reg [get_integer_valueof "\$sp" 0]
+       set sp_reg [get_valueof /u "\$sp" 0]
        gdb_test_no_output "guile (define byte-at-sp (parse-and-eval \"*(char*) \$sp\"))" \
            "save current value at sp"
        # Pass the result of parse-and-eval through value-fetch-lazy!,