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]

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


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.

> 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?
I have to think over that, because my generated C code does not use
volatile.
Did you commit the patch?
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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]