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

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


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