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.
See also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19020
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: 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.
