digitalmars.D.learn - DbC bug?
- Magnus Lie Hetland (25/25) Feb 23 2012 I think I've stumbled across a DbC bug. In an out-block, I have the
- H. S. Teoh (8/19) Feb 23 2012 [...]
- Magnus Lie Hetland (21/23) Feb 27 2012 Indeed. After spending quite a while whittling down my code, I've
I think I've stumbled across a DbC bug. In an out-block, I have the assertion `assert(id < objs.length);`. Now, if I don't have an in-block, this fails. However, if I add an in-block (with basically any code that isn't optimized away, or so it seems), the assertion succeeds. (Before this was an assertion, the failure was a range violation from objs[id]; the behavior is equivalent for that.) And this happens even though both id and objs are const...(!) And: If I place the same assertion just before the return statement (which just returns the result, without any computation), the assertion before return succeeds, but the one immediately inside the out block fails. Unless, of course, there is an in block, which magically fixes everything (without really doing anything). It seems that the id variable (a parameter of the method) is actually undefined in the out-block, and that this is the reason for the error. (The program is run with the same random seeds, but the id variable, which *should* be in 0..1000, ends up with varying values such as 1609528144, 1653547856 or 1816621904. I'm guessing this is a bug in the DbC functionality, somehow? Is it a known bug? (Couldn't find anything relevant -- but then again, I wasn't sure exactly what to search for...) My code runs lots of experiments, and this only happens after the method has been used a *lot* (i.e., this doesn't happen all the time -- though it *does* happen every time the program is run) -- which means producing a minimal example would require some effort... :-}
Feb 23 2012
On Thu, Feb 23, 2012 at 11:42:35AM +0100, Magnus Lie Hetland wrote:I think I've stumbled across a DbC bug. In an out-block, I have the assertion `assert(id < objs.length);`. Now, if I don't have an in-block, this fails. However, if I add an in-block (with basically any code that isn't optimized away, or so it seems), the assertion succeeds. (Before this was an assertion, the failure was a range violation from objs[id]; the behavior is equivalent for that.)[...]It seems that the id variable (a parameter of the method) is actually undefined in the out-block, and that this is the reason for the error. (The program is run with the same random seeds, but the id variable, which *should* be in 0..1000, ends up with varying values such as 1609528144, 1653547856 or 1816621904.[...] Looks like a compiler bug. You should never be able to access invalid values. T -- "A man's wife has more power over him than the state has." -- Ralph Emerson
Feb 23 2012
On 2012-02-23 15:59:18 +0000, H. S. Teoh said:Looks like a compiler bug. You should never be able to access invalid values.Indeed. After spending quite a while whittling down my code, I've module main; import std.conv; class Class { void method(uint arg) in { // assert(arg + 1); // Uncomment to prevent bug } out { assert(arg == 0, "BUG: arg == " ~ to!string(arg)); } body {} } void main(string[] args) { (new Class).method(0); } -- Magnus Lie Hetland http://hetland.org
Feb 27 2012