Strange warning: Dword data exceeds bounds

[Serge]

Compiled the following:

Code: [Select]

cpu 386
and eax, 1<<31The result is OK.
Now compiled the following:

Code: [Select]

cpu 386
and eax, ~(1<<30)The result is OK also.
Finally compiled the following:

Code: [Select]

cpu 386
and eax, ~(1<<31)and received warning "dword data exceeds bounds".
I stuck upon this code for a long time being drawing the bit positions and shaking my head. All is OK, – the ~(1<<31) is the last bit cleared. The "~" operator is bitwise, so both initial data and the result are unsigned. All higher bits doesn't matter.
Please check that and remove that warning if no actual data loss.

[Frank Kotler]

This is a legitimate bug. I've posted it to the bug-tracker. Thanks for the feedback!

Best,
Frank

[Frank Kotler]

FYI, here's the feedback from the bug-tracker:

----------------------------------------------------------------------

> >Comment By: H. Peter Anvin (hpa)
Date: 2011-07-23 14:10

Message:
The right hand expression has the value of 0xFFFF_FFFF_7FFF_FFFF which is
correctly not either sign- or zero-extendable from the 32-bit truncated
value.  The issue here is the handling of - or ~ in these kinds of
expressions: they end up extending an expression theoretically "to
infinity", even though that is presumably not the intention of the
programmer.
----------------------------------------

I take this to mean: "Ignore the warning!"

Best,
Frank

[Frank Kotler]

More feedback from the bug-tracker...

----------------------------------------------------------------------

Comment By: nasm64developer (nasm64developer)
Date: 2011-07-23 23:09

Message:
> > even though that is presumably not the
> > intention of the programmer.

The programmer's intent is not clear from
the code. Yes, EAX suggests 32 bits... but
no, it's not sufficient to suggest that there
should be no bounds warnings.

The programmer should explicitly specify
mov eax, 0xFFFFFFFF & (~(1<<31)) so that
the 32-bit intent becomes non-ambiguous
and the warning goes away.

----------------------------------------------------------------------

Best,
Frank

[Serge]

Yeah, I know about 0xFFFFFFFF & (~(1<<31))
The thing is that no one bit in upper 32 bits is actually meaningful after shift and inversion. So masking them out is just a "lotion" to get rid of warning.

[Cyrill Gorcunov]

The programmer should explicitly specify
mov eax, 0xFFFFFFFF & (~(1<<31)) so that
the 32-bit intent becomes non-ambiguous
and the warning goes away.

I don't agree with nasm64developer here, I didn't manage to look if we can do something with it but such constructions
look to me like I would have to type

Code: [Select]

int var = 0xFFFFFFFF & (~(1<<31))

in C code, this is somehow... inconvenient

[Serge]

Me too.
I think that there is slightly broken logic here. As far as I can get, the NASM sees that the sign bit is changed (from negative to positive) and not propagated to the upper half. But actually the same logic implies that (1<<31) without inversion also changes the sign bit (now from positive to negative) which is also not propagated to upper half. But in this case NASM doesn't warn about probable data loss. Why?
To be consistent, both cases (with and without inversion) should work identically. But removing warning seems to me more adequate.

[Cyrill Gorcunov]

It's not that simple from internal code structure. I hope we will fix it one day.