On Tue, Jul 29, 2014 at 1:17 PM, Thomas Mertes <thomas.mer...@gmx.at> wrote: > On Mon, Jul 28, 2014 at 11:49 AM, Richard Biener <richard.guent...@gmail.com> > wrote: >> 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. > > 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.
