This is the mail archive of the
`gcc@gcc.gnu.org`
mailing list for the GCC project.

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |

Other format: | [Raw text] |

*From*: Richard Biener <richard dot guenther at gmail dot com>*To*: Thomas Mertes <thomas dot mertes at gmx dot at>*Cc*: GCC Development <gcc at gcc dot gnu dot org>*Date*: Mon, 28 Jul 2014 11:49:45 +0200*Subject*: Re: C as intermediate language, signed integer overflow and -ftrapv*Authentication-results*: sourceware.org; auth=none*References*: <trinity-ef56f8a7-8da6-40a9-aea6-658df9967fbc-1406127365897 at 3capp-gmx-bs23> <53D01359 dot 9060708 at LimeGreenSocks dot com> <CAFiYyc3oEdfEcqQvucp-DHGanCZ4Q+oV++Ggb9cypwyfskE++g at mail dot gmail dot com> <trinity-cd88fe45-1800-4151-8a0b-cf48a7b97d33-1406277813651 at 3capp-gmx-bs47> <CAFiYyc0A3qqz7zqN6Fym177YC29pm-9gEmPes4LR-XerEMfo=A at mail dot gmail dot com> <trinity-78b512d9-062c-423a-85d1-72fa2f6917f1-1406445202376 at 3capp-gmx-bs04>

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.

**Follow-Ups**:**Aw: Re: C as intermediate language, signed integer overflow and -ftrapv***From:*Thomas Mertes

**References**:**C as intermediate language, signed integer overflow and -ftrapv***From:*Thomas Mertes

**Re: C as intermediate language, signed integer overflow and -ftrapv***From:*David Wohlferd

**Re: C as intermediate language, signed integer overflow and -ftrapv***From:*Richard Biener

**Re: C as intermediate language, signed integer overflow and -ftrapv***From:*Thomas Mertes

**Re: C as intermediate language, signed integer overflow and -ftrapv***From:*Richard Biener

**Re: C as intermediate language, signed integer overflow and -ftrapv***From:*Thomas Mertes

Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|

Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |