[Issue 6205] Strongly-pure nothrow functions with ignored return value are entirely stripped even if it contains a failing 'assert'.
http://d.puremagic.com/issues/show_bug.cgi?id=6205 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added CC||verylonglogin@gmail.com --- Comment #7 from Kenji Hara k.hara...@gmail.com 2012-01-09 02:07:12 PST --- *** Issue 6827 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6205] Strongly-pure nothrow functions with ignored return value are entirely stripped even if it contains a failing 'assert'.
http://d.puremagic.com/issues/show_bug.cgi?id=6205 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #6 from Walter Bright bugzi...@digitalmars.com 2012-01-05 12:34:26 PST --- https://github.com/D-Programming-Language/dmd/commit/ead4a879100a43e44b0321f3d31341fd43b6aab7 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6205] Strongly-pure nothrow functions with ignored return value are entirely stripped even if it contains a failing 'assert'.
http://d.puremagic.com/issues/show_bug.cgi?id=6205 --- Comment #4 from Kenji Hara k.hara...@gmail.com 2012-01-04 03:07:56 PST --- I think this is 'too early optimization' bug. Mechanism: 1. The calling of a function that is strong-pure and nothrow is 'no side effect'. Then dmd marks it in IR level. https://github.com/D-Programming-Language/dmd/blob/master/src/e2ir.c#L286 2. OPucallns and OPcallns are completely removed in backend optimizer level. https://github.com/D-Programming-Language/dmd/blob/master/src/backend/cgelem.c#L4088 https://github.com/D-Programming-Language/dmd/blob/master/src/backend/cgelem.c#L4385 The mistaken is in #1. assert() has 'implicit side effect' (throw AssertError, or halt), so all of function call with enabling assertion should disable 'remove no side effect calling' optimization. At least, a compilation without -O switch should not remove such calls. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6205] Strongly-pure nothrow functions with ignored return value are entirely stripped even if it contains a failing 'assert'.
http://d.puremagic.com/issues/show_bug.cgi?id=6205 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||patch --- Comment #5 from Kenji Hara k.hara...@gmail.com 2012-01-04 04:24:59 PST --- https://github.com/D-Programming-Language/dmd/pull/607 Only `-O -release` specification ignite the optimization. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6205] Strongly-pure nothrow functions with ignored return value are entirely stripped even if it contains a failing 'assert'.
http://d.puremagic.com/issues/show_bug.cgi?id=6205 Jonathan M Davis jmdavisp...@gmx.com changed: What|Removed |Added CC||jmdavisp...@gmx.com --- Comment #1 from Jonathan M Davis jmdavisp...@gmx.com 2011-06-24 01:29:19 PDT --- I'm not sure that this is a bug. It's a strongly pure function. It _is_ nothrow, which means that it won't throw any Exception, and its return value isn't used. assert is more of a debugging tool than anything. Sure, assert(false) sticks around in release mode, but still. Based on the purity and nothrow rules, this function can be optimized out of existance. I really don't see a problem with this. Now, assuming that is indeed the correct behavior, the obviously runnable/test41.d needs to be fixed, but it looks to me like having the call to x optimized out of existance makes perfect sense. And if the assert doesn't get hit, then it doesn't get hit. Asserts are intended primarily for debugging purposes. Yes, it's an assert(false) and not a normal assert, but still, if we start worrying about whether an assert would have killed a function or not, then we won't be able to optimize out functions like this, which wouldn't be good IMHO. Now, assuming that it's really only an issue when you have a strongly pure function where you throw away its return value, then maybe that's not a big deal, because that's bad code on the part of the programmer anyway, but I'm still inclined to think that it makes sense for x to never be called in this code (at least if optimizations are turned on). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6205] Strongly-pure nothrow functions with ignored return value are entirely stripped even if it contains a failing 'assert'.
http://d.puremagic.com/issues/show_bug.cgi?id=6205 --- Comment #2 from kenn...@gmail.com 2011-06-24 02:06:12 PDT --- Pull request for test41 if this is considered INVALID: https://github.com/D-Programming-Language/dmd/pull/162 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6205] Strongly-pure nothrow functions with ignored return value are entirely stripped even if it contains a failing 'assert'.
http://d.puremagic.com/issues/show_bug.cgi?id=6205 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #3 from Don clugd...@yahoo.com.au 2011-06-24 02:30:58 PDT --- The bug is that the compiler's behaviour isn't consistent. It's reasonable to optimize the function away in this case -- but then, it should generate an 'expression has no effect' warning. See bug 3882. This test case is an excellent justification for treating 3882 as a bug, rather than an enhancement. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
