Re: Dealing with ambiguities in GAS

[Geoffrey Keating <geoffk at geoffk dot org>]

Mark Mitchell <mark@codesourcery.com> writes:

> 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?

What about

        .8byte foo-2147483649

where 'foo' is a symbol?