tag:blogger.com,1999:blog-6042417775578107106.post8667790569522624941..comments2023-08-05T11:30:32.754-04:00Comments on The Hacks of Life: The Dangers of Super Smart CompilersChrishttp://www.blogger.com/profile/14648675681957285299noreply@blogger.comBlogger13125tag:blogger.com,1999:blog-6042417775578107106.post-77009713674123521122016-05-11T07:49:31.180-04:002016-05-11T07:49:31.180-04:00just a minor correction
it seems the problem is no...just a minor correction<br />it seems the problem is not in rhs, but in this,<br />"operator* returns *m_ptr"<br /><br />operator* return a reference, and it can't be null<br />so clang evaluates == null as always false<br /><br />in the solution to the problem clang has no choice but to evaluate both operandsA-dr Polt-kyhttps://www.blogger.com/profile/16134124481888834805noreply@blogger.comtag:blogger.com,1999:blog-6042417775578107106.post-48012065525174030022016-01-18T07:16:37.912-05:002016-01-18T07:16:37.912-05:00GCC has done the same thing before. It broke one o...GCC has done the same thing before. It broke one of SPEC 2006 tests by optimizing a function into a infinite loop:<br />http://blog.regehr.org/archives/918<br />However GCC developers decided to "fix" that optimization just before release.Anonymoushttps://www.blogger.com/profile/17669429321821732824noreply@blogger.comtag:blogger.com,1999:blog-6042417775578107106.post-72798711367528882632016-01-01T03:40:30.764-05:002016-01-01T03:40:30.764-05:00Another interesting case:
// Global definition
st...Another interesting case:<br /><br />// Global definition<br />struct Thing { char a[3]; };<br /><br />// One file<br />ptrdiff_t subtract(struct Thing *a, struct Thing *b) { return a - b; }<br /><br />// Another file<br />char data[1];<br />printf("%td\n", subtract((struct Thing *)(data + 1), (struct Thing *)data));<br /><br />No optimization: 0<br />Full optimization: 0<br />Optimization but no link-time optimization: -6148914691236517205<br /><br />Alternatively, you could do this:<br /><br />struct Thing thing;<br />printf("%td\n", subtract(&thing + 4000000000000000000, &thing));<br /><br />No optimization: -2148914691236517205<br />Full optimization: -2148914691236517205<br />Optimization but no link-time optimization: 4000000000000000000<br /><br />You're welcome. Happy new year!Jonathanhttps://www.blogger.com/profile/02937438632589368418noreply@blogger.comtag:blogger.com,1999:blog-6042417775578107106.post-42669108930367837992015-12-31T12:04:12.840-05:002015-12-31T12:04:12.840-05:00Hah! You've got to love Clang. It's tellin...Hah! You've got to love Clang. It's telling you it's all your fault, which you can't deny! I do worry about this development because it means programmers must become language lawyers to prevent things from breaking willy-nilly. A lot of programmers don't care very much, let alone know all the rules.<br /><br />I also question the use of making things like signed integer overflow undefined. I think it was originally put there to deal with some signed formats and trapping hardware (although that could be implementation-defined). Does it have to be repurposed like that? Sure, it allows for some optimizations, but it's not quite as obvious what's going on when it works perfectly fine until the optimizer sees an opportunity. That kind of 'undefined' is bound to cause obscure bugs.Jonathanhttps://www.blogger.com/profile/02937438632589368418noreply@blogger.comtag:blogger.com,1999:blog-6042417775578107106.post-9360057617465746392015-12-29T15:07:19.516-05:002015-12-29T15:07:19.516-05:00Some more interesting docs about how clang optimiz...Some more interesting docs about how clang optimizes const objects:<br /><br />https://docs.google.com/document/d/112O-Q_XrbrU1I4P-oiLCN9u86Qg_BYBdcDsmh7Pn9Nw/mobilebasicAnonymoushttps://www.blogger.com/profile/01254919523217180099noreply@blogger.comtag:blogger.com,1999:blog-6042417775578107106.post-62390566192355800092015-12-26T14:09:01.641-05:002015-12-26T14:09:01.641-05:00That's a great Raymond post. And yep...clang/l...That's a great Raymond post. And yep...clang/llvm is -very- post classical. :-) This is the first time in production code that I've seen this kind of "undefined code? we'll optimize by nuking the entire code block" type behavior.Benjamin Supnikhttps://www.blogger.com/profile/04886313844644521178noreply@blogger.comtag:blogger.com,1999:blog-6042417775578107106.post-51153565338227644962015-12-26T13:17:00.010-05:002015-12-26T13:17:00.010-05:00I didn't know we already got at least one &quo...I didn't know we already got at least one "post-classical" compiler in the wild as described by Raymond Chen:<br />https://blogs.msdn.microsoft.com/oldnewthing/20140627-00/?p=633/ His description quite fits...Klimaxhttps://www.blogger.com/profile/13343327313499033969noreply@blogger.comtag:blogger.com,1999:blog-6042417775578107106.post-25050161477723306812015-12-23T11:09:42.864-05:002015-12-23T11:09:42.864-05:00It wouldn't matter - the thing we're takin...It wouldn't matter - the thing we're taking an address of is -already- a null reference (because we applied * to a nullptr_t) and thus we are already in undefined-bizarro-land.Benjamin Supnikhttps://www.blogger.com/profile/04886313844644521178noreply@blogger.comtag:blogger.com,1999:blog-6042417775578107106.post-60275794764584088112015-12-23T11:07:51.007-05:002015-12-23T11:07:51.007-05:00Totally true! It's not an easy transition for ...Totally true! It's not an easy transition for old-timers like me who used to think we knew what the 'undefined' behavior was actually doing. With compiler technology 15 years ago, you could probably know what code would be generated for your target architecture and you might go "well, that's fine."<br /><br />Clearly now is not then and Clang is just going to astonish us with wizardry until we all shape up. :-)Benjamin Supnikhttps://www.blogger.com/profile/04886313844644521178noreply@blogger.comtag:blogger.com,1999:blog-6042417775578107106.post-28681208720610107952015-12-23T09:56:15.400-05:002015-12-23T09:56:15.400-05:00Interesting post -- thanks for that!
Not sure i...Interesting post -- thanks for that! <br /><br />Not sure if any of the techniques described here would have helped in your case, but there's a good overview of how clang deals with undefined behavior at:<br /><br />http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_21.html<br />Anonymoushttps://www.blogger.com/profile/01254919523217180099noreply@blogger.comtag:blogger.com,1999:blog-6042417775578107106.post-73894923295450382022015-12-20T21:22:58.972-05:002015-12-20T21:22:58.972-05:00I forgive youI forgive youAnonymoushttps://www.blogger.com/profile/08915240893699033323noreply@blogger.comtag:blogger.com,1999:blog-6042417775578107106.post-53908714533194217792015-12-20T09:31:07.511-05:002015-12-20T09:31:07.511-05:00I'm not sure whether that's your goal, but...I'm not sure whether that's your goal, but if you'd like to obtain the underlying object's address, why not simply use std::addressof instead?<br /><br />http://en.cppreference.com/w/cpp/memory/addressofMatthttps://www.blogger.com/profile/03155815661102270775noreply@blogger.comtag:blogger.com,1999:blog-6042417775578107106.post-69148412639048419822015-12-20T08:26:02.101-05:002015-12-20T08:26:02.101-05:00Your post should be named The danger of code havin...Your post should be named The danger of code having undefined behavior.Unknownhttps://www.blogger.com/profile/00623784970576464946noreply@blogger.com