On Wed, Jul 23, 2014 at 9:56 PM, David Wohlferd <d...@limegreensocks.com> 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 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) overflow checking. Richard. > 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. >> >
