[Issue 8521] New: Internal error: e2ir.c 720 when a function uses a template which relies on that function and -release and -inline are used

d-bugmail at puremagic.com d-bugmail at puremagic.com
Wed Aug 8 00:18:02 PDT 2012


http://d.puremagic.com/issues/show_bug.cgi?id=8521

           Summary: Internal error: e2ir.c 720 when a function uses a
                    template which relies on that function and -release
                    and -inline are used
           Product: D
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: blocker
          Priority: P2
         Component: DMD
        AssignedTo: nobody at puremagic.com
        ReportedBy: jmdavisProg at gmx.com


--- Comment #0 from Jonathan M Davis <jmdavisProg at gmx.com> 2012-08-08 00:18:00 PDT ---
This is currently a blocker for phobos pull request# 743, which make stride,
strideBack, and decode work with arbitrary ranges of code units, which is
needed for the D lexer for Phobos that I'm working on.

This is the reduced code:

import std.traits;

void main()
{
    auto tmp = "hello";
    size_t i = 0;
    decode(tmp, i);
}

template isRange(R)
{
    enum bool isRange = is(typeof(
    {
        R r = void;
        auto w = r.front;
    }));
}

@property dchar front(A)(A a)
{
    size_t i = 0;
    return decode(a, i);
}

dchar decode(S)(auto ref S str, ref size_t index)
{
    return decodeImpl(str, index);
}

private dchar decodeImpl(S)(auto ref S str, ref size_t index)
{
    enum canIndex = isRange!S;

    assert(0);
}


It compiles just fine normally, but when you compile with -release and -inline
together, it fails to compile, giving this error:

decodeImpl(S)
Internal error: e2ir.c 720

I think that the problem stems from the fact that isRange depends on decode,
which in turn depends on isRange, and something about the inlining process
screws it up. Moving the line with isRange from decodeImpl into decode makes
the problem going away as does removing front from inside of isRange. And using
decode inside of isRange makes it go away as well. So, it seems that the number
of levels of indirection has to be at at least a certain level before the
failure occurs.

The code in pull request# 743 passes its unit tests just fine as long as you
don't compile with both -release and -inline, so clearly the code can work, but
something about -release and -inline screws it up.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------


More information about the Digitalmars-d-bugs mailing list