Dealing with ambiguities in GAS

[Mark Mitchell]

When confronted with a negative number which requires 33 bits to require 
as a signed value, but 32 as an unsigned value (i.e., a number X smaller 
than INT_MIN, but such that abs(X) is smaller than UINT_MAX), GAS 
silently converts the number to the unsigned value.

That works OK with 32-bit data directives, but with a 64-bit data 
directive, it loses.  For example, given:

  .8byte -X

with X a literal in the indicated range, GAS will zero the four 
high-order bytes, rather than filling them with 0xff as desired.

GCC does not generally use the .8byte directive unless configured with a 
64-bit HOST_WIDE_INT.  So, the problem is when GCC is using 64-bit 
HOST_WIDE_INT, but GAS is using 32-bit integers.

It's not terribly easy to fix this in GAS (because GAS doesn't really 
know which quantities are signed) and old versions of GAS will be out 
there for some time, so I've been thinking about avoiding this problem 
in GCC.  My current idea is to have default_assembler_integer return 
false for sizes greater than HOST_WIDE_INT, which would force 
assemble_integer to break bigger values into word-sized chunks.

Do people see problems with that approach?

-- 
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com