Re: Re: C as intermediate language, signed integer overflow and -ftrapv

[Richard Biener <richard dot guenther at gmail dot com>]

On Tue, Jul 29, 2014 at 1:17 PM, Thomas Mertes <thomas.mertes@gmx.at> wrote:
> On Mon, Jul 28, 2014 at 11:49 AM, Richard Biener <richard.guenther@gmail.com> wrote:
>> On Sun, Jul 27, 2014 at 9:13 AM, Thomas Mertes <thomas.mertes@gmx.at> wrote:
>> > On Fri, Jul 25, 2014 at 12:35, Richard Biener <richard.guenther@gmail.com> wrote:
>> >> On Fri, Jul 25, 2014 at 10:43 AM, Thomas Mertes <thomas.mertes@gmx.at> wrote:
>> >> > On Thu, Jul 24 at 10:36 PM, Richard Biener <richard.guenther@gmail.com> wrote:
>> >> >> Fact is that if somebody is interested in
>> >> >> -ftrapv he/she is welcome to contribute patches.  Especially testing
>> >> >> coverage is poor.
>> >> >
>> >> > As I said I have test programs for integer overflow (not written
>> >> > in C). Now I have converted one test program to C. This program
>> >> > checks if an int64_t overflow raises SIGABRT or SIGILL. The name of
>> >> > the program is chkovf64.c and I have uploaded it to
>> >> >
>> >> >   http://sourceforge.net/projects/seed7/files/
>> >> >
>> >> > It is licenced with GPL. You can use it to improve the testing
>> >> > coverage of gcc. When I compile it with:
>> >> >
>> >> >   gcc -ftrapv chkovf64.c -o chkovf64
>> >> >
>> >> > it writes a lot of warnings about "integer overflow in expression".
>> >> > Running chkovf64 shows that -ftrapv does not work correct.
>> >>
>> >> That's https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61893 - basically
>> >> as soon as we can constant-fold we lose the trap.  Which is probably
>> >> not important for practical purposes, but you have a point here.
>> >
>> > For human programmers it is probably ok to have a warning instead of
>> > the trap. But when the C program has been generated (C as intermediate
>> > language) it is important that the trap is not lost.
>> >
>> > Isn't possible that constant-fold has the result "it will overflow"?
>> > Hopefully it is not necessary to omit an optimization because of -ftrapv.
>> > For my use-case that would be bad. I need -ftrapv together with all
>> > optimizations for production code and NOT for debugging purposes.
>>
>> Well.  The optimization would be to transform known overflows to
>> __builtin_trap ().  Not sure what optimization you are thinking of
>> otherwise.
>
> I would be bad if -ftrapv would switch off some optimizations.
>
>> >> > Maybe all -ftrapv problems uncovered by chkovf64.c are because
>> >> > of this. Unfortunately there are also other test cases where
>> >> > a signal is not raised although a signed integer overflow occurred.
>> >> > This happens in a much bigger program and until now I was not
>> >> > able to create a simple test case from it.
>> >>
>> >> Yes, not all optimizations may be aware of -ftrapv.
>> >
>> > In the case above (the much bigger program) the error (overflow without
>> > raising SIGABRT) happens when I compile without -O and without -g.
>> > When I use -g the signal SIGABRT is raised. I still don't have a simple
>> > test case, sorry.
>> >
>> > Did you have a look at chkovf64.c?
>>
>> With my latest patches it passes at -O0 -ftrapv but still fails partly with
>> optimization:
>>
>> > ./a.out
>>  ***** Negation -(-9223372036854775808) does not always raise a signal.
>>  ***** Overflow checking of negation does not work correct.
>>  ***** Addition underflow by one does not always raise a signal. (1)
>>  ***** Addition underflow by one does not always raise a signal. (2)
>>  ***** Addition underflow by one does not always raise a signal. (3)
>>  ***** Addition underflow by one does not always raise a signal. (4)
>>  ***** Addition overflow by one does not always raise a signal. (1)
>>  ***** Addition overflow by one does not always raise a signal. (2)
>>  ***** Addition overflow by one does not always raise a signal. (3)
>>  ***** Addition overflow by one does not always raise a signal. (4)
>>  ***** Addition underflow does not always raise a signal.
>>  ***** Addition overflow does not always raise a signal.
>>  ***** Overflow checking of addition does not work correct.
>> ***** Addition assignment underflow by one does not always raise a signal. (1)
>>  ***** Addition assignment underflow by one does not always raise a signal. (2)
>>  ***** Addition assignment underflow by one does not always raise a signal. (3)
>>  ***** Addition assignment underflow by one does not always raise a signal. (4)
>>  ***** Addition assignment overflow by one does not always raise a signal. (1)
>>  ***** Addition assignment overflow by one does not always raise a signal. (2)
>>  ***** Addition assignment overflow by one does not always raise a signal. (3)
>>  ***** Addition assignment overflow by one does not always raise a signal. (4)
>>  ***** Addition assignment underflow does not always raise a signal.
>>  ***** Addition assignment overflow does not always raise a signal.
>>  ***** Overflow checking of addition assignment does not work correct.
>>  ***** Subtraction underflow by one does not always raise a signal. (1)
>>  ***** Subtraction underflow by one does not always raise a signal. (2)
>>  ***** Subtraction underflow by one does not always raise a signal. (3)
>>  ***** Subtraction underflow by one does not always raise a signal. (4)
>>  ***** Subtraction overflow by one does not always raise a signal. (1)
>>  ***** Subtraction overflow by one does not always raise a signal. (2)
>>  ***** Subtraction overflow by one does not always raise a signal. (3)
>>  ***** Subtraction overflow by one does not always raise a signal. (4)
>>  ***** Subtraction underflow does not always raise a signal.
>>  ***** Subtraction overflow does not always raise a signal.
>>  ***** Overflow checking of subtraction does not work correct.
>>  ***** Subtraction assignment underflow by one does not always raise a
>> signal. (1)
>>  ***** Subtraction assignment underflow by one does not always raise a
>> signal. (2)
>>  ***** Subtraction assignment underflow by one does not always raise a
>> signal. (3)
>>  ***** Subtraction assignment underflow by one does not always raise a
>> signal. (4)
>>  ***** Subtraction assignment overflow by one does not always raise a
>> signal. (1)
>>  ***** Subtraction assignment overflow by one does not always raise a
>> signal. (2)
>>  ***** Subtraction assignment overflow by one does not always raise a
>> signal. (3)
>>  ***** Subtraction assignment overflow by one does not always raise a
>> signal. (4)
>>  ***** Subtraction assignment underflow does not always raise a signal.
>> ***** Subtraction assignment overflow does not always raise a signal.
>>  ***** Overflow checking of subtraction assignment does not work correct.
>>  ***** Overflow checking of incr does not work correct.
>>  ***** Overflow checking of decr does not work correct.
>>  ***** Underflow when computing multiplication does not always raise a
>> signal. (1)
>>  ***** Underflow when computing multiplication does not always raise a
>> signal. (2)
>>  ***** Underflow when computing multiplication does not always raise a
>> signal. (3)
>>  ***** Underflow when computing multiplication does not always raise a
>> signal. (4)
>>  ***** Overflow when computing multiplication does not always raise a
>> signal. (1)
>>  ***** Overflow when computing multiplication does not always raise a
>> signal. (2)
>>  ***** Overflow when computing multiplication does not always raise a
>> signal. (3)
>>  ***** Overflow when computing multiplication does not always raise a
>> signal. (4)
>> ***** Overflow checking of multiplication does not work correct.
>>  ***** Underflow when computing multiplication assignment does not
>> always raise a signal. (1)
>>  ***** Underflow when computing multiplication assignment does not
>> always raise a signal. (2)
>>  ***** Underflow when computing multiplication assignment does not
>> always raise a signal. (3)
>>  ***** Underflow when computing multiplication assignment does not
>> always raise a signal. (4)
>>  ***** Overflow when computing multiplication assignment does not
>> always raise a signal. (1)
>>  ***** Overflow when computing multiplication assignment does not
>> always raise a signal. (2)
>>  ***** Overflow when computing multiplication assignment does not
>> always raise a signal. (3)
>>  ***** Overflow when computing multiplication assignment does not
>> always raise a signal. (4)
>>  ***** Overflow checking of multiplication assignment does not work correct.
>>
>> > Is it useable as test program for -ftrapv?
>>
>> I'm not sure if catching SIGABRT and SIGILL only is sufficient on all
>> targets (for my testcases I chose to fork (), wait () and verify if the exit
>> status is != 0).
>
> The exception handling I use is based on sigsetjmp and it works under
> Linux, BSD and Windows with different C compilers. Besides the things
> you said about volatile I think sigsetjmp (and setjmp when sigsetjmp
> is not present) together with signal respectively sigaction can be
> used for exception handling.
>
>> I'm also not sure the testcase is not optimized in a bogus
>> way because sigsetjmp doesn't necessarily behave as barrier for
>> optimizers (AFAIK 'cnt', 'ok' and 'okay' have to be volatile as they
>> live across a setjmp call).  Also 'num' is dead and GCC feels free to
>> eliminate dead
>> computations even if they trap.
>
> With clang chkovf64.c works without a change even with optimizations:
>
>   clang -O3 -ftrapv chkovf64.c -o chkovf64
>   ./chkovf64
>
> writes:
>
> Overflow checking of negation works correct.
> Overflow checking of addition works correct.
> Overflow checking of addition assignment works correct.
> Overflow checking of subtraction works correct.
> Overflow checking of subtraction assignment works correct.
> Overflow checking of incr works correct.
> Overflow checking of decr works correct.
> Overflow checking of multiplication works correct.
> Overflow checking of multiplication assignment works correct.

I wonder what clang disables in optimization when seeing sigsetjmp
though ;)

>> Making all vars volatile seem to fix the optimization results.
>
> Interesting.
> When the vars are volatile and with your latest patch chkovf64.c
> succeeds also with optimizations?

No.  It seems to only help

Overflow checking of addition works correct.

but I haven't looked into the other cases in detail (the testcase is
too big ...)

> I have to think over that, because my generated C code does not use
> volatile.

Well, usually computed values are used in some way (in some way
other than generating a trap).

> Did you commit the patch?

https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01945.html

is still missing.

Richard.

> For me it seems like a step in the right direction.
>
> For the bigger program with the overflow error I have still no small
> test case. This will probably take some time.
>
> Greetings Thomas Mertes
>
> --
> Seed7 Homepage:  http://seed7.sourceforge.net
> Seed7 - The extensible programming language: User defined statements
> and operators, abstract data types, templates without special
> syntax, OO with interfaces and multiple dispatch, statically typed,
> interpreted or compiled, portable, runs under linux/unix/windows.