regression with huge integer

[mec dot gnu at mindspring dot com (Michael Elizabeth Chastain)]

gdb.stabs/weird.def has this huge integer:

  # 256-bit integer.  The point is obviously not that GDB should have a
  # special case for this size, but that an integer of any size should
  # work (at least for printing in hex, not necessarily for arithmetic.  
  .stabs "int256var:G203=bu32;0;256;", N_GSYM,0,0, 0
  # The value is palindromic, so it works whether words are big or little
  # endian.  
  .globl int256var
  .data
  .align_it
       int256var:
  .long 42
       .long 0x2b, 0x2c, 0x2d, 0x2d, 0x2c, 0x2b, 0x2a

gdb 6.0 can print this just fine:

  (gdb) print int256var
  $1 = 0x0000002a0000002b0000002c0000002d0000002d0000002c0000002b0000002a
  (gdb) print /x int256var
  $2 = 0x0000002a0000002b0000002c0000002d0000002d0000002c0000002b0000002a

But with the recent simplification to print_scalar_formatted, gdb HEAD says:

  (gdb) print int256var
  $1 = 0x0000002a0000002b0000002c0000002d0000002d0000002c0000002b0000002a
  (gdb) print /x int256var
  $2 = That operation is not available on integers of more than 8 bytes.

This causes a regression in the test results.

I would like to just accept this output and change the test script.
Specifically, in gdb.stabs/weird.exp:

	  # This big number needs to be kept as one piece
  - 	gdb_test "p/x int256var" " = 0x0*2a0000002b0000002c0000002d0000002d0000002c0000002b0000002a" "print very big integer"
  + 	gdb_test "print int256var" " = 0x0*2a0000002b0000002c0000002d0000002d0000002c0000002b0000002a" "print very big integer"
    
Is this a good idea?  Or should I file a bug that "print /x" does not work
in this case?

Michael C