Bug with -ftree-vrp?

Bug with -ftree-vrp?

[Alexey Neyman]

Howdy,

I stumbled over this misbehavior while debugging some problem in 
Wireshark. The problem has been reduced to the test case below (a 
simplified snippet from the time_secs_to_str_buf() function in 
Wireshark):

<<<<<
#include <stdio.h>

void foo(int v)
{
        if (v < 0) {
                v = -v;
        }
        if (v < 0) {
                fprintf(stderr, "bad number\n");
                return;
        }
        fprintf(stderr, "[%d]\n", v);
}

int main(void)
{
        foo(0x80000000);
        return 0;
}
<<<<<<

The problem is that with -O2, the second conditional gets optimized 
away. However, such optimization results in a misbehavior for the 
minimum number representable in 32 bits, 0x80000000. The option which 
triggers this optimization is -ftree-vrp.

I would consider this a bug in VRP, since (judging by the description of 
the -ftree-vrp option), this option is only supposed to eliminate 
equivalent ranges.

Regards,
Alexey.

Best regards,
Alexey Neyman.

Re: Bug with -ftree-vrp?

[Brian Dessent]

Alexey Neyman wrote:

> The problem is that with -O2, the second conditional gets optimized
> away. However, such optimization results in a misbehavior for the
> minimum number representable in 32 bits, 0x80000000. The option which
> triggers this optimization is -ftree-vrp.

Signed integer overflow is undefined in ISO C.  If v = INT_MIN then v =
-v is undefined, and hence the compiler can assume this won't occur and
optimize away the test since a conformant program does not invoke
undefined behavior.  Yes, there is some debate around the legitimacy of
this optimization because "traditional" C has more or less held that
signed integer overflow is perfectly defined on all two's compliment
machines (i.e. everywhere.)  But the standard leaves it undefined and so
gcc is within its right to do this optimization, so say the language
lawyers.

You may be interested in the options -fno-strict-overflow, -fwrapv, and
-Wstrict-overflow.

Brian