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

           Summary: Optimization (register allocation?) regression in DMD
                    1.065
           Product: D
           Version: D1
          Platform: x86
        OS/Version: Windows
            Status: NEW
          Keywords: ice-on-valid-code
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: thecybershadow@gmail.com
                CC: thecybershadow@gmail.com


--- Comment #0 from Vladimir <thecybershadow@gmail.com> 2011-01-14 18:51:29 PST ---
Created an attachment (id=871)
Partially minimized test case

I've stumbled upon a rather weird regression, which was introduced in DMD 1.065: when compiling specific code with -O -release -inline, it ICEs with "Internal error: ..\ztc\cgcod.c 1649".

The test case seems to be quite resistant to "minimization", and even moving functions from one module to another seems to make the bug vanish. I've reduced the test case to four modules, and somewhat minimized the first two, but I'm willing to give up for now at this point. If any compiler developer decides that minimizing the test case is worth it, I'll give it another shot as soon as I get over my cold.

As I went to post this, I noticed that I was still using DMD 1.065. However, DMD 1.066 outright crashes.

To reproduce, compile the attached files with:

dmd -O -release -inline Common.d Data.d Gzip.d Zlib.d

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

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


Don <clugdbug@yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |clugdbug@yahoo.com.au
            Version|D1                          |D1 & D2


--- Comment #1 from Don <clugdbug@yahoo.com.au> 2011-01-17 00:22:27 PST ---
This doesn't fail in the D1 version in svn.
This doesn't ICE on svn 852 "reduce reliance on varargs" but did ICE on svn 851
and earlier.
Here's a slightly reduced test case which ICEs on the version of D2 in svn.
Still requires -O -inline -release.
----
final class DataWrapper
{
    void* dat;

    void[] contents()
    {
        return dat[0..1];
    }
}

class Data
{
private:
    DataWrapper wrapper;
    size_t start, end;

public:
    this(void[] data) {}
    size_t length()
    {
        return end - start;
    }
}

Data daz(Data srcbuf)
{
    throw new Exception("xxx");
}

uint crc32(void[] data)
{
    int w;
    foreach(v;cast(ubyte[])data)
    {
        ++w;
    }
    return 0;
}


class HttpResponse
{
    Data zug;

    void setContent(Data data, string[] supported)
    {
        foreach(method;supported)
            switch(method)
            {
                default:
                    uint[] footer = [crc32(data.wrapper ?
data.wrapper.contents[data.start..data.end] : null ), data.end - data.start];
                    zug = daz(data);
                    return;
            }
    }
}
----

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

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


Don <clugdbug@yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Optimization (register      |ICE(cgcod.c): Optimization
                   |allocation?) regression in  |(register allocation?)
                   |DMD 1.065                   |regression in DMD 1.065
           Severity|normal                      |regression


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

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



--- Comment #2 from Don <clugdbug@yahoo.com.au> 2011-01-17 11:44:32 PST ---
This is amazing. I have never before seen such an irreducible test case. Here's the best I've been able to do.
-----
void thrw(Data *s) {
    throw new Exception("xxx");
}

struct Data {
    Rapper *w;
    uint n, m;
}

struct Rapper {
    ubyte * dat;
    ubyte[] con() {
        return dat[0..1];
    }
}

uint jaz(ubyte[] data) {
    return data.length;
}

struct Resp {
    void set(Data *data, string[] soup) {
        switch(soup[0]) {
            default:
        }
        uint[] f = [jaz(data.w ? data.w.con[data.n ..data.m] : null), data.m -
data.n];
        thrw(data);
    }
}

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

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



--- Comment #3 from Don <clugdbug@yahoo.com.au> 2011-01-18 12:44:11 PST ---
I think there's something wrong in cgcod.c, allocreg(). Might be good to have
an assert on line 1920:


                r &= mLSW;                      /* see if there's an LSW also
*/
                if (r)
                    lsreg = findreg(r);
                else if (lsreg == -1)   /* if don't have LSW yet */
                {       retregs &= mLSW;
+                   assert(retregs);
                    goto L3;
                }
            }

This fails. What happens is, we've found a register for the MSW. But we got called with no available LSW registers!

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

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



--- Comment #4 from Don <clugdbug@yahoo.com.au> 2011-01-24 14:03:21 PST ---
The regression was introduced in git revision
0eb915bf22045b3c34f23e63859bf8361b2d5a7a, 2010-10-24
with the helpful commit comment "more 64 bit stuff".

That commit was TYint-> TYsizet changes, so it shouldn't have had any effect at all on the generated code for 32 bits.

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

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



--- Comment #5 from Don <clugdbug@yahoo.com.au> 2011-01-25 00:27:34 PST ---
The bug was triggered by this change to SliceExp::toElem() (now line 4426):

---
        elem *eptr = array_toPtr(e1->type, e);
-        elem *elength = el_bin(OPmin, TYint, eupr, elwr2);
+        elem *elength = el_bin(OPmin, TYsize_t, eupr, elwr2);
        eptr = el_bin(OPadd, TYnptr, eptr, el_bin(OPmul, TYsize_t,
el_copytree(elwr2), el_long(TYsize_t, sz)));

        e = el_pair(TYdarray, elength, eptr);
        e = el_combine(elwr, e);
        e = el_combine(einit, e);
---
Reverting this change removes the ICE.
TYsize_t is a TYuint, rather than a TYint.
Still, I don't understand why it makes any difference.

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

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



--- Comment #6 from Don <clugdbug@yahoo.com.au> 2011-01-25 13:07:25 PST ---
I think what's happened, is that a minor change to support 64 bits has triggered a latent bug in the backend.

Basically, cgreg_assign() in cgreg.c thinks there are enough free registers. But allocreg() in cgcod.c can't find one. Although it is called with two available registers, one of them is EBP, and EBP is disallowed in line 1910. So these two functions are inconsistent.

I think the problem may be in creg_assign(). It thinks it has freed up a
register (EBX) which is used for 'this'. But (if I've correctly understood what
the code is doing) the same register seems to be used in a double-reg combo.
Seems a bit similar to bug 4443.
If I'm correct, then a solution to this bug would be to check if the register
is also part of a double-reg variable, before marking it as freed-up.

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

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


Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |bugzilla@digitalmars.com
         Resolution|                            |FIXED


--- Comment #7 from Walter Bright <bugzilla@digitalmars.com> 2011-02-11 22:59:37 PST ---
https://github.com/D-Programming-Language/dmd/commit/55da7194b3f626d1183fcd5404597749e4e21e15

https://github.com/D-Programming-Language/dmd/commit/bf6d6884d68783fb4007bfe6fa9f125a77538ef2

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