This is the mail archive of the
mailing list for the GCC project.
Re: C as intermediate language, signed integer overflow and -ftrapv
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: David Wohlferd <dw at limegreensocks dot com>
- Cc: Thomas Mertes <thomas dot mertes at gmx dot at>, GCC Development <gcc at gcc dot gnu dot org>
- Date: Thu, 24 Jul 2014 10:36:57 +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>
On Wed, Jul 23, 2014 at 9:56 PM, David Wohlferd <firstname.lastname@example.org> wrote:
> I believe that sometimes gcc is promoting the ints to long longs when doing
> the overflow testing. If I try to overflow a long long, I get the trap as
Yes, I think that's one issue - see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52478 - it's probably
also the most important
bug to fix in the current implementation (but also not the easiest).
Fact is that if somebody is interested in
-ftrapv he/she is welcome to contribute patches. Especially testing
coverage is poor.
Note that the way to go forward with -ftrapv is doing it different than
currently. See comments in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48580
There is now -fsanitize=undefined which provides (heavier weight)
> See also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19020
> On 7/23/2014 7:56 AM, Thomas Mertes wrote:
>> C is popular as intermediate language. This means that some compilers
>> generate C and use a C compiler as backend. Wikipedia lists several
>> languages, which use C as intermediate language:
>> Eiffel, Sather, Esterel, some dialects of Lisp (Lush, Gambit),
>> Haskell (Glasgow Haskell Compiler), Squeak's Smalltalk-subset Slang,
>> Cython, Seed7 and Vala.
>> When C is used as backend the features needed from a C compiler are
>> different from the features that a human programmer of C needs.
>> One such feature is the detection of signed integer overflow. It is
>> not hard, to detect signed integer overflow with a generated C
>> program, but the performance is certainly not optimal. Signed integer
>> overflow is undefined behavior in C and the access to some overflow
>> flag of the CPU is machine dependent. So the generated C code must
>> recogize overflow before it happens or use unsigned computations and
>> recognize the overflow afterwards. I have doubts that this leads to
>> optimal performance.
>> The C compiler is much better suited to do signed integer overflow
>> checks. The C compiler can do low level tricks, that would be
>> undefined behavior in C, and the C compiler also knows about overflow
>> flags and other details of the CPU. Maybe the CPU can be switched to
>> a mode where it traps signed integer overflow for free.
>> The gcc compiler option -ftrapv promises to do exactly that, but it
>> seems broken. At least my test suite shows that both gcc version
>> 4.6.3 and 4.8.1 fail to detect integer overflow with -ftrapv. The
>> detection fails even for addition and subtraction. I know that 4.6.3
>> and 4.8.1 are old, but I found nothing in the internet that tells
>> me that the situation is better now. So for gcc as C compiler backend
>> -ftrapv cannot be used and overflow checking in the generated C code
>> is necessary.
>> Clang supports -ftrapv reliably. Signed integer overflow raises the
>> signal SIGILL, which can be catched. Btw. SIGILL seems to be a better
>> choice, because under windows (7) SIGABRT causes some text to be
>> written to the console. Is it possible to choose a -ftrapv signal?
>> A sanitizer such as ubsan is good as tool to find errors in C
>> programs. But I don't think that ubsan is well suited to do overflow
>> detection with maximum performance. Is just not the goal of this
>> The argumantation that nobody uses -ftrapv is self-fulfilling
>> prophecy. How can someone expect that a buggy feature is used.
>> The counterexample is clang, where -ftrapv works and is also used
>> (E.g. by the integer overflow detection of Seed7).
>> Signed integer overflow detection with -ftrapv is NOT something that
>> nobody uses. It is an important feature. Especially when C is used as
>> intermediate language. When it works it results in a significant
>> speed up of signed overflow detection. A sanitizer has a different
>> purpose and cannot be used as replacement.
>> I can offer some help with this issue:
>> I have test programs for cases with integer overflow and for cases
>> where the result is as big or as small as possible without causing an
>> overflow. The test programs are not written in C, but are licensed
>> with the GPL, and it would be possible to convert them to C with
>> reasonable effort. Maybe this is not necessary, because clang must
>> have some test suites for -ftrapv.
>> 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.