Re: [PATCH] gas value truncation warning reports truncated values, doesn't look at signedness.

[Bart Samwel]

Alan Modra wrote:
> > We've had a discussion on the linux-kernel mailing list about a warning 
> > that was generated by gas. The warning was correct, but it reported the 
> > same value for the truncated and the original value. It turns out that 
> > the warning prints unsigned longs, while the truncated values were 
> > unsigned long longs.
>
> The reason for this is that up until just recently, binutils has been
> written in K&R C, which has no long long type.  We could not use %ll
> in error messages either.  I suppose we could have written functions
> to print out these errors properly, but obviously no one cared enough
> to make such a contribution.

OK, I understand why it wasn't there yet. If you're up to ANSI C++ now, 
a fix would be nice. :)

> > Then I found another issue: the warning is issued 
> > for ~0x80000000 (which is correct, because this yields 
> > 0xffffffff7fffffff) but not for ~0x7fffffff (which is incorrect, because 
> > this yields 0xffffffff80000000). The problem: the warning code assumes 
> > that the value is signed, even if it is really unsigned (like ~0x7fffffff).
>
> I think you are confused over the rules for the type of an integer
> constant.  Assuming 32 bit ints, the type of 0x7fffffff is "int", but
> the type of 0x80000000 is "unsigned int".  Thus ~0x8000000 is
> 0x7fffffff, *not* 0xffffffff7fffffff as you claim.

Hmmm, then there is probably a bug in gas. The reason: why does the 
warning happen on 0xffffffff7fffffff instead of 0x000000007fffffff as 
the original value? Try using this code:

foo: .long ~(0x80000000)

I've expanded the error message to give me long long data (and the 
mask/unmask values). It gives me:

test.S: Assembler messages:
test.S:2: Warning: value 0xffffffff7fffffff truncated to 0x7fffffff, 
mask = ffffffff00000000, unmask = ffffffff

This means that ~0x80000000 is interpreted as 0xffffffff7fffffff, not 
0x7fffffff, according to gas. You're assuming 32-bit ints, but my 
offsetT is apparently 64-bit. I'm using linux 2.6.1-mm2 on an i386 
architecture. Do you have any idea what can cause this? I use gcc "gcc 
(GCC) 3.3.3 20031229 (prerelease) (Debian)".

> > The attached patch (against binutils 2.14) fixes this by upgrading the 
> > warning's format string to %Lx, and by taking into account the 
>
> Thanks, but %L is glibc specific.  %ll is the correct modifier.

Didn't know that, thanks. :)

-- BArt