This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Dealing with ambiguities in GAS


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]