D issues are now tracked on GitHub. This Bugzilla instance remains as a read-only archive.
Issue 8790 - Compiling with optimization produces erroneous variable initialization error
Summary: Compiling with optimization produces erroneous variable initialization error
Status: RESOLVED DUPLICATE of issue 8556
Alias: None
Product: D
Classification: Unclassified
Component: dmd (show other issues)
Version: D2
Hardware: All Linux
: P2 regression
Assignee: No Owner
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-10-09 17:41 UTC by hsteoh
Modified: 2012-10-09 19:22 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description hsteoh 2012-10-09 17:41:02 UTC
import std.algorithm;
import std.range;

void main() {
    auto N2 = sequence!"n"(cast(size_t)1).map!"a";
}


When compiling with dmd -O (latest git for dmd, druntime, phobos), this produces the following errors:

/usr/src/d/phobos/std/range.d(4590): Error: variable upper used before set
/usr/src/d/phobos/std/range.d(4590): Error: variable lower used before set

The referenced line of code occurs in this context:

    auto opSlice(size_t lower, size_t upper)
    in
    {  
        assert(upper >= lower); // this is line 4590
    }
    body
    {  
        auto s = typeof(this)(this._state, this._n + lower);
        return takeExactly(s, upper - lower);
    }

Which makes no sense, because there is nothing wrong with the reference to upper and lower (they are function parameters). Perhaps the optimizer inadvertently permuted the order of stuff in a way that caused the contract to run before the parameters are initialized?

If -O is not specified, the compile is successful. This problem appears to be independent of whether I specify -m32 or -m64.
Comment 1 Jonathan M Davis 2012-10-09 19:22:06 UTC
I believe that this is a duplicate of bug# 8556. I suspect that at least part of the problem is that takeExactly checks hasSlicing, so if you're using takeExactly to do slicing, it's going to cause problems right now. I'm almost finished on a pull request which will fix that, and that may or may not make it so that this bug doesn't manifest itself with sequence, but if anything, that means that we'd need to find another way to reproduce this bug, because that will just fix the Phobos part, not the compiler bug.

*** This issue has been marked as a duplicate of issue 8556 ***