-
Notifications
You must be signed in to change notification settings - Fork 123
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Maximum negative value for -Wint-overflow off by one? #817
Comments
Just saw that H.7.4 does map SV data types to C types and found LONG_MIN to be -2147483647 in the standard. |
In the C definition, INT_MIN is -32767, but neither of the following give a warning. I increased the value to be an even larger negative number and still didn't get a warning. Is the literal value always being assumed to be 32-bit? class C;
function f();
shortint a = -32768;
shortint b = shortint'(-32768);
endfunction
endclass |
So there's a few things happening here. First, literal integers without a base are always 32-bits (or larger; the LRM 5.7.1 says "The number of bits that make up an unsized number (which is a simple decimal number or a number with a Second, there isn't really such a thing as a negative literal integer; the minus sign is the minus operator applied to the positive literal. That's why you're getting that warning; the lexer produces the integer token and sees that it overflows the positive bounds. The minus sign then gets applied to that overflowed value, but in two's complement negating the most negative integer like that just produces the same most negative value, so you end up with the right result anyway. I could add something to suppress the warning in this case because it's kind of unhelpful, but VCS does issue the same warning so maybe it's helpful to have parity?
For the shortint case, you don't get the same warning because the integer literal is still a signed 32-bit value and it fits comfortably. You should get a Wconstant-conversion warning when assigned to a shortint because the value gets truncated, but for some reason that's not working. I'll fix that. Finally, the C definitions for INT_MIN / LONG_MIN in specification only provide min values (that are symmetric with their positive values, in case an implementation doesn't use two's complement I guess). Actual implementations use values that match the real bounds of their types, for example with gcc on x86_64 INT_MIN is |
Also LRM 11.3.3 has more light on this subject:
|
Thanks for the references. |
Using -32'sd214783648 does resolve the Slang (and presumably VCS) warning, but the shortint case with an explicit 16-bit signed format doesn't trigger the warning. Would you expect it to? e.g. shortint a = -16'sd32769; |
Yes indeed, there's a warning -Wvector-overflow which I think should trigger in this case but it's not considering the sign bit when checking. |
Issues in this thread should be fixed now. |
I think there is an off-by-one issue for -Wint-overflow, but I couldn't find any discussion of the boundary values in the LRM.
I was expecting a signed variable to allow values ranging from -2^31 to 2^31-1, but it looks like the int-overflow check is only allowing -2^31+1 to 2^31-1
The text was updated successfully, but these errors were encountered: