Re: Building current

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> Right.  The .s file has $-1 for that operand and the instruction
>> stream generated has 8f ff ff ff ff 00 00 00 00, which is immediate
>> mode with a value of 00000000ffffffff.
> In my eyes that definitely looks like a gas bug.

Normally, I'd agree.  However, as I said upsthread, I haven't seen a
language spec.  It strikes as at least possible that in gas, all values
are unsigned and that arithmetic (such as - applied to 1) is specified
to ignore all but the low 32 bits on input and generate all-0 bits
above the low 32 bits on output.  Those would, collectively, account
for this.  It sounds a bit schizoid, but I can easily see incremental
changes plus "don't break existing code" compatability concerns leading
to such a (possibly unwritten) spec.

The main reason I look for reasons to exonerate gas is that gcc has
demonstrated an ability to generate "$0xffffffffffffffff" for the value
in question, which leads me to wonder why it didn't do so for the ashq.
That's whence the speculation about some codepath losing track of the
width of the value, leading (putatively) gcc to generate code for
4294967295 (producing $-1) rather than 18446744073709551615 (producing
$0xffffffffffffffff).

> That's a zero-extended 32-bit -1 into a 64-bit value.  Do gas regard
> the immediate value as unsigned?

I don't know, though I'm very tempted to say "apparently".

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B