On Sun, Jul 27, 2014 at 9:13 AM, Thomas Mertes <thomas.mer...@gmx.at> wrote: > On Fri, Jul 25, 2014 at 12:35, Richard Biener <richard.guent...@gmail.com> > wrote: >> On Fri, Jul 25, 2014 at 10:43 AM, Thomas Mertes <thomas.mer...@gmx.at> wrote: >> > On Thu, Jul 24 at 10:36 PM, Richard Biener <richard.guent...@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.
