www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 2773] New: problem compiling a big program with -O -inline -release

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2773

           Summary: problem compiling a big program with -O -inline -release
           Product: D
           Version: 1.041
          Platform: PC
        OS/Version: Windows
            Status: NEW
          Keywords: rejects-valid
          Severity: regression
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla digitalmars.com
        ReportedBy: aliloko gmail.com


When compiling with dmd -O -inline -release, dmd hangs up and I get the
following error message. 
I did'nt succeeded in isolating the problem. The bug appear only with all three
arguments (-O -inline -release).


Internal Error : ..\ztc\go.c 243

The corresponding line in the back-end source code is :

243 :    assert(++iter < 200);  /* infinite loop check           */


-- 
Mar 31 2009
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2773






I cannot do anything with this without a reproducible example.

But I suggest that to work around, split your large function into a couple
smaller ones.


-- 
Apr 01 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2773






Created an attachment (id=312)
 --> (http://d.puremagic.com/issues/attachment.cgi?id=312&action=view)
Reduced test case.

Attached is a reduced test case (can't spend time on it now but wanted to
attach this.)

Compile with:

dmd -O -inline -release -c 2773_reduced.d

Bug occurs in DMD 1.041 and DMD 2.026, most likely in 2.027 as well.

-[Unknown]


-- 
Apr 03 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2773






The error is different in DMD 2.027.

dmd -O -inline -release -c 2773_reduced.d
Internal error: ..\ztc\go.c 243


-- 
Apr 03 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2773






Created an attachment (id=313)
 --> (http://d.puremagic.com/issues/attachment.cgi?id=313&action=view)
Workaround patch: make endless iteration not an error.

Please note: this patch does not fix this bug.

I suggest dropping the assert for iter, and instead treating it the same as the
clock timeout.  While this makes this class of bug less discoverable, I propose
that it's better that it compiles - at least some functions will be optimized.

Regarding this bug - it keeps moving an equation to optimize it, so each time
the loop runs it's got more changes.  Unfortunately, the innards of the backend
are still a bit beyond me, so I can't see why.

Note that the second call to pointer.clear() can be a call to another method,
on the same struct, as long as that method does something (anything.)

Also, reducing the size of the static array below 3 (or making it dynamic)
solves it, but a bigger one still dies.  Changing the code within clear() to
any other operation also solves it.  And the struct has to be within a class,
returned from a method.

-[Unknown]


-- 
Apr 03 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2773


Don <clugdbug yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|ICE(go.c) compiling a big   |ICE(go.c) array assignment
                   |program with -O -inline     |through a pointer, only
                   |-release                    |with -O.





Here's a slightly reduced test case, which only requires -O (doesn't need
-inline -release), and ICEs on both D1 and D2. On D2, you still get an ICE if
you remove all references to the class, and just set S2773* pointer = &dat.

struct S2773{
  int[4] data;    
}

S2773 dat;

class C2773 {
  S2773* get()    {  return &dat;  }
}

void main()
{
  C2773 inst = null;
  S2773* pointer = inst.get();
  pointer.data[] = 0;
  pointer.data[] = 0;
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 20 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2773


Don <clugdbug yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|regression                  |critical





This isn't a regression. It failed on DMD1.022 as well, which was released in
mid-2007, almost 2 years before this bug report.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Aug 31 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2773




Even simpler test case, this one fails on both D1.033 and 1.048.
int[4]* get()    {  return null; }

void main()
{
  int[4]* p = get();
  (*p)[] = 0;
  (*p)[] = 0;
}

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 05 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2773


Don <clugdbug yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |patch



An even simpler test case shows something interesting: it happens only when
there's an array assignment of 0, followed by another use of the same variable.
An array assignment to 0 is an OPmemset operation in the backend.

int* get()  {  return null; }
void main(){
  int* p = get();
  p[0..3] = 0; // must be = 0!! Doesn't happen with any other number.
  p[0] = 7;
}

ANALYSIS:
This is an OPmemset fight! In the optimisation loop, there's a localize step
which rearranges the assignment, and there's a canonicalize step which sets it
back the way it was before....

cgelem.c,  elmemxxx() line 702 replaces ((e op= v) op e2) with ((e op=v), (e op
e2))
ie,  (p = get()), p) memset 0.   ---> ((p = get()), p memset 0.

glocal.c,  local_exp() replaces
p = get(); p memset 0; ---> (p = get(), p) memset 0

So it just keeps going round in circles.
The fight can be broken up by changing cgelem.c elmemxxx() line 701 
to avoid doing the first replacement:

-            if (e1->Eoper == OPcomma || OTassign(e1->Eoper))
+            if (e1->Eoper == OPcomma)

This probably isn't correct, there may be somewhere this particular
canonicalisation is important. But without the DMC test suite, I can't tell.
(Note that the comments in the code only refer to the OPcomma transformation,
not the assignment one, so I presume the assignment was a later addition).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 06 2009
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=2773


Walter Bright <bugzilla digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED



14:10:07 PDT ---
Fixed dmd 1.049 and 2.034

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