This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH RFC: -Wstrict-overflow
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