digitalmars.D.bugs - [Issue 2773] New: problem compiling a big program with -O -inline -release
- d-bugmail puremagic.com (21/21) Mar 31 2009 http://d.puremagic.com/issues/show_bug.cgi?id=2773
- d-bugmail puremagic.com (6/6) Apr 01 2009 http://d.puremagic.com/issues/show_bug.cgi?id=2773
- d-bugmail puremagic.com (12/12) Apr 03 2009 http://d.puremagic.com/issues/show_bug.cgi?id=2773
- d-bugmail puremagic.com (6/6) Apr 03 2009 http://d.puremagic.com/issues/show_bug.cgi?id=2773
- d-bugmail puremagic.com (20/20) Apr 03 2009 http://d.puremagic.com/issues/show_bug.cgi?id=2773
- d-bugmail puremagic.com (28/28) May 20 2009 http://d.puremagic.com/issues/show_bug.cgi?id=2773
- d-bugmail puremagic.com (11/11) Aug 31 2009 http://d.puremagic.com/issues/show_bug.cgi?id=2773
- d-bugmail puremagic.com (13/13) Oct 05 2009 http://d.puremagic.com/issues/show_bug.cgi?id=2773
- d-bugmail puremagic.com (36/36) Oct 06 2009 http://d.puremagic.com/issues/show_bug.cgi?id=2773
- d-bugmail puremagic.com (11/11) Oct 13 2009 http://d.puremagic.com/issues/show_bug.cgi?id=2773
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
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
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
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
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
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
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
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
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
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