This is the mail archive of the 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]

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

On Wed, Jul 23, 2014 at 9:56 PM, David Wohlferd <> 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
> expected.

Yes, I think that's one issue - see - 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

There is now -fsanitize=undefined which provides (heavier weight)
overflow checking.


> See also
> dw
> 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
>> tool.
>> 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).
>> Conclusion:
>> 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:
>> 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]