Ian Lance Taylor - Re: PATCH RFC: -Wstrict-overflow (original) (raw)

This is the mail archive of the gcc-patches@gcc.gnu.orgmailing 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]

Alexandre Oliva aoliva@redhat.com writes:

The subtraction is irrelevant here.

Err... Surely you're not telling me that the code below invokes undefined behavior:

I meant that in the specific example under discussion the subtraction was irrelevant.

int f(int x, int y) { return x - y; } int main() { return f(INT_MIN, INT_MIN); }

Because if you say the subtraction is irrelevant, it appears to me that you're saying the compiler is permitted to convert x-y to x+(-y) and trap if -y overflows. I wouldn't have thought so.

No, of course not. When signed overflow traps, we do not perform any of these transformations.

In this case the transformation is from - (A / B) to (A / - B).

Given 6.5.6/6, no, this is not what the transformation is about. What the user wrote was C - (A / B), not C + (- (A / B)), so assuming it was the latter and propagating the overflow on the grounds that the original program would trigger it is faulty, because the original program wouldn't. The first transformation is only valid when it does not visibly affect the result, but if we proceed to the second transformation, then it does. So the transformation is invalid, should be avoided, and the warning is undeserved.

The compiler transforms (A - B) to (A + (- B)) when it is safe and cheap to negate B (fold-const.c line 9318). The compiler considers negating (B / C) to be safe and cheap when it is safe and cheap to negate either B or C. In the case at hand, bytes -= bitsize / BITS_PER_UNIT; C is a constant which is safe and cheap to negate.

This shows a general principle with -Wstrict-overflow: we warn when we make any transformation which would not be permitted if we were using -fwrapv.

I guess this warning has exposed a bug in the compiler, then?

I don't think so. But I do now think you're right that there is a bug in my warning messages. I don't have to issue a warning for negating A / B if we don't rely on undefined signed overflow to decide that negating A or B is cheap. In this case negating the constant shouldn't make a difference in the calculation, as far as I can see.

Ian

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