www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - DbC bug?

reply Magnus Lie Hetland <magnus hetland.org> writes:
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
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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
parent Magnus Lie Hetland <magnus hetland.org> writes:
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