www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Undefined behaviors & Clang 3.3

reply "bearophile" <bearophileHUGS lycos.com> writes:
Another nice post about the Integer Undefined Behavior Detection 
of Clang 3.3:

http://blog.regehr.org/archives/963

Until these languages die, which isn’t going to happen anytime 
soon, our best defense against undefined behaviors is to write 
better checking tools.<
Some potential bugs it has found: http://article.gmane.org/gmane.comp.fonts.freetype.devel/8817 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57324 http://blog.regehr.org/extra_files/perl-test-output.txt Things like this in gcc: gcc/gcc/simplify-rtx.c:4004:16: runtime error: signed integer overflow: -1844674407370955161 + -9223372036854775808 cannot be represented in type 'long' gcc/gcc/stor-layout.c:2543:45: runtime error: signed integer overflow: -9223372036854775808 - 1 cannot be represented in type 'long' Is someone able to compile and run the dmd source code with Clang with "-fsanitize=undefined"? And is it possible to add -fsanitize=undefined to ldc2? Bye, bearophile
Jun 20 2013
next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Thursday, 20 June 2013 at 14:28:42 UTC, bearophile wrote:
 Another nice post about the Integer Undefined Behavior 
 Detection of Clang 3.3:

 http://blog.regehr.org/archives/963

Until these languages die, which isn’t going to happen anytime 
soon, our best defense against undefined behaviors is to write 
better checking tools.<
Some potential bugs it has found: http://article.gmane.org/gmane.comp.fonts.freetype.devel/8817 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57324 http://blog.regehr.org/extra_files/perl-test-output.txt Things like this in gcc: gcc/gcc/simplify-rtx.c:4004:16: runtime error: signed integer overflow: -1844674407370955161 + -9223372036854775808 cannot be represented in type 'long' gcc/gcc/stor-layout.c:2543:45: runtime error: signed integer overflow: -9223372036854775808 - 1 cannot be represented in type 'long' Is someone able to compile and run the dmd source code with Clang with "-fsanitize=undefined"? And is it possible to add -fsanitize=undefined to ldc2? Bye, bearophile
I also advise those with Apple accounts to have a look at the WWDC 2013 videos, there are a few sessions about LLVM optimizations and auto-vectorization in Clang. Maybe those features could benefit LDC as well. -- Paulo
Jun 20 2013
prev sibling parent reply "qznc" <qznc web.de> writes:
On Thursday, 20 June 2013 at 14:28:42 UTC, bearophile wrote:
 Another nice post about the Integer Undefined Behavior 
 Detection of Clang 3.3:

 http://blog.regehr.org/archives/963

Until these languages die, which isn’t going to happen anytime 
soon, our best defense against undefined behaviors is to write 
better checking tools.<
Some potential bugs it has found: http://article.gmane.org/gmane.comp.fonts.freetype.devel/8817 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57324 http://blog.regehr.org/extra_files/perl-test-output.txt Things like this in gcc: gcc/gcc/simplify-rtx.c:4004:16: runtime error: signed integer overflow: -1844674407370955161 + -9223372036854775808 cannot be represented in type 'long' gcc/gcc/stor-layout.c:2543:45: runtime error: signed integer overflow: -9223372036854775808 - 1 cannot be represented in type 'long' Is someone able to compile and run the dmd source code with Clang with "-fsanitize=undefined"? And is it possible to add -fsanitize=undefined to ldc2? Bye, bearophile
In D an integer overflow is defined, so there is no need to detect anything about it. See Spec: "If both operands are of integral types and an overflow or underflow occurs in the computation, wrapping will happen. That is, uint.max + 1 == uint.min and uint.min - 1 == uint.max." http://dlang.org/expression.html
Jun 21 2013
next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
qznc:

 In D an integer overflow is defined, so there is no need to 
 detect anything about it.
A language should offer the programmer a way to specify when an integral overflow is acceptable. Otherwise the other cases are bugs. Clang 3.3 helps find some of those bugs. Bye, bearophile
Jun 21 2013
parent reply "eles" <eles eles.com> writes:
On Friday, 21 June 2013 at 10:42:32 UTC, bearophile wrote:
 qznc:

 In D an integer overflow is defined, so there is no need to 
 detect anything about it.
A language should offer the programmer a way to specify when an integral overflow is acceptable. Otherwise the other cases are bugs. Clang 3.3 helps find some of those bugs.
I just wanted to say almost the same thing: that the original sentence should read: "In D an integer overflow is *badly or, at least, questionably and inflexibly* defined, so there is no *possibility* to detect anything *useful* about it." Well, that was the flame for today.
Jun 21 2013
next sibling parent reply Artur Skawina <art.08.09 gmail.com> writes:
On 06/21/13 15:48, eles wrote:
 On Friday, 21 June 2013 at 10:42:32 UTC, bearophile wrote:
 qznc:

 In D an integer overflow is defined, so there is no need to detect anything
about it.
A language should offer the programmer a way to specify when an integral overflow is acceptable. Otherwise the other cases are bugs. Clang 3.3 helps find some of those bugs.
I just wanted to say almost the same thing: that the original sentence should read: "In D an integer overflow is *badly or, at least, questionably and inflexibly* defined, so there is no *possibility* to detect anything *useful* about it." Well, that was the flame for today.
Actually, it's the other way around - mandating wrapping is what makes it possible for code to detect the overflow. Having overflow be undefined (C-like) means that the compiler as allowed to remove all code that checks for or relies on the overflow happening. Mandating /trapping/ on OF would be a bad idea for perf reasons, You can implement both trapping and saturating arithmetic on top of wrapping. As the people wanting these will either a) don't really care about bare metal performance or a) use h/w acceleration (simd etc) anyway, it isn't really a problem. artur
Jun 21 2013
parent "eles" <eles eles.com> writes:
On Friday, 21 June 2013 at 14:48:46 UTC, Artur Skawina wrote:
 On 06/21/13 15:48, eles wrote:
 On Friday, 21 June 2013 at 10:42:32 UTC, bearophile wrote:
Actually, it's the other way around - mandating wrapping is what makes it possible for code to detect the overflow. Having overflow be
Very much aware of that. However, going from undefined to (badly) defined is not the best choice, as long as better is available.
Jun 21 2013
prev sibling parent reply "qznc" <qznc web.de> writes:
On Friday, 21 June 2013 at 13:48:19 UTC, eles wrote:
 On Friday, 21 June 2013 at 10:42:32 UTC, bearophile wrote:
 qznc:

 In D an integer overflow is defined, so there is no need to 
 detect anything about it.
A language should offer the programmer a way to specify when an integral overflow is acceptable. Otherwise the other cases are bugs. Clang 3.3 helps find some of those bugs.
I just wanted to say almost the same thing: that the original sentence should read: "In D an integer overflow is *badly or, at least, questionably and inflexibly* defined, so there is no *possibility* to detect anything *useful* about it." Well, that was the flame for today.
The D definition mirrors what modern PC architectures do and hence can be compiled efficiently there. C avoids coupling with any architecture hence "undefined". What architectures do not wrap around?
Jun 21 2013
next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Friday, 21 June 2013 at 15:51:55 UTC, qznc wrote:
 The D definition mirrors what modern PC architectures do and 
 hence can be compiled efficiently there. C avoids coupling with 
 any architecture hence "undefined".

 What architectures do not wrap around?
Some used to have +0 and -0 and so wrapping around do not work. But this didn't survived (or maybe in some exotic not heavily used chips). Similarly, some arch used to use different values than 0 for null. I don't know any modern one that does it.
Jun 21 2013
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 6/21/2013 8:51 AM, qznc wrote:
 The D definition mirrors what modern PC architectures do and hence can be
 compiled efficiently there. C avoids coupling with any architecture hence
 "undefined".
 What architectures do not wrap around?
C is a very old language, and supported many architectures that no longer exist, such as ones-complement machines, machines with 10 bit bytes, weird floating point formats, EBCDIC, 16 bit CPUs, etc. A lot of C code tries to be "portable" to all these no-longer-existing machines, and a lot of effort is wasted. But D has the luxury of taking advantage of the fact that things have converged on 2s-complement, IEEE 754 floating point, 8 bit bytes, Unicode, etc. This means we can now nail down many implementation-defined and undefined behaviors.
Jun 21 2013
prev sibling next sibling parent reply "eles" <eles eles.com> writes:
On Friday, 21 June 2013 at 15:51:55 UTC, qznc wrote:
 On Friday, 21 June 2013 at 13:48:19 UTC, eles wrote:
 On Friday, 21 June 2013 at 10:42:32 UTC, bearophile wrote:
The D definition mirrors what modern PC architectures do and hence can be compiled efficiently there. C avoids coupling with any architecture hence "undefined".
First, it is not just about UNDEFINED behaviour, but also about DESIRED behaviur. C's arrays seen as pointers were efficient (and mirroring the architecture who kne nothing about arrays, just about addresses, that is pointers), still D abandoned them for a good reason. Efficiency vs better is a sensible trade-off. Secondly, is just enabling that overflow behavior if chasing a bug, explicitely, with a compiler flag. Use it only if you care. Although the best solution, in my eyes, is to have both wrapping and overfloing signed and unsigned integer types. Chose what you want.
 What architectures do not wrap around?
They wrap, but they carry. BTW, floats do not wrap, why integers should behave otherwise?
Jun 21 2013
parent reply "Simen Kjaeraas" <simen.kjaras gmail.com> writes:
On Sat, 22 Jun 2013 02:14:18 +0200, eles <eles eles.com> wrote:

 BTW, floats do not wrap, why integers should behave otherwise?
Because that's how the hardware works. IEEE-754 floats have special values that do not behave like other numbers: infinity and nan. The ints the hardware supports have no such thing. Of course, one could write a complex wrapper around the int to get infinity in there, and even nan if one really wanted, but that'd be a lot less efficient, and contrary to how people expect things to work. -- Simen
Jun 22 2013
parent "eles" <eles eles.com> writes:
On Saturday, 22 June 2013 at 07:59:05 UTC, Simen Kjaeraas wrote:
 On Sat, 22 Jun 2013 02:14:18 +0200, eles <eles eles.com> wrote:
 Of course, one could write a complex wrapper around the int to 
 get infinity
 in there, and even nan if one really wanted, but that'd be a 
 lot less
 efficient, and contrary to how people expect things to work.
They would never carry when wrapping up if that would have been the case.
Jun 24 2013
prev sibling parent "renoX" <renozyx gmail.com> writes:
On Friday, 21 June 2013 at 15:51:55 UTC, qznc wrote:
 What architectures do not wrap around?
The MIPS has instructions which trap on integer overflow (it has other which wrap too). Unfortunately, this is the only CPU I know where you can have a sane integer semantic "for free". renoX
Jun 25 2013
prev sibling parent Artur Skawina <art.08.09 gmail.com> writes:
On 06/21/13 10:20, qznc wrote:
 In D an integer overflow is defined, so there is no need to detect anything
about it. See Spec:
 
 "If both operands are of integral types and an overflow or underflow occurs in
the computation, wrapping will happen. That is, uint.max + 1 == uint.min and
uint.min - 1 == uint.max."
 http://dlang.org/expression.html
Keep in mind that this is not necessarily how real compilers treat it: void main() { auto a = int.max; if (a+1<a.max) assert(0); } will not assert when compiled with gdc; you'd have to explicitly disable that optimization. GCC statically evaluates this kind of checks, by assuming that signed overflow can't happen - because it's undefined. But that's not true for D, so, until the compiler is fixed, the '-fno-strict-overflow' compiler flag has to be used if "spec"-like behaviour is desired. Requiring wrapping arithmetic removes some opportunities for optimization, hence should, ideally, be complemented by more value range awareness in the language. D doesn't really have the latter, so right now, avoiding the UB in these cases has a cost. Still, GDC should just be fixed, as having a subtly different dialect is worse. Right now, incorrect (according to the "spec") code is silently generated, causing data corruption. artur
Jun 21 2013