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

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

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.

>> > 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).  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.

Making all vars volatile seem to fix the optimization results.

Richard.

> 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.