[Issue 2773] ICE(go.c) array assignment through a pointer, only with -O.

[via Digitalmars-d-bugs]

https://issues.dlang.org/show_bug.cgi?id=2773

Walter Bright bugzi...@digitalmars.com changed:

   What|Removed |Added

Version|1.041   |D1

--

[Issue 2773] ICE(go.c) array assignment through a pointer, only with -O.

[d-bugmail]

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


Walter Bright bugzi...@digitalmars.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


--- Comment #9 from Walter Bright bugzi...@digitalmars.com 2009-10-13 
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: ---

[Issue 2773] ICE(go.c) array assignment through a pointer, only with -O.

[d-bugmail]

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


Don clugd...@yahoo.com.au changed:

   What|Removed |Added

   Keywords||patch


--- Comment #8 from Don clugd...@yahoo.com.au 2009-10-06 00:17:14 PDT ---
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: ---

[Issue 2773] ICE(go.c) array assignment through a pointer, only with -O.

[d-bugmail]

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



--- Comment #7 from Don clugd...@yahoo.com.au 2009-10-05 03:12:06 PDT ---
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: ---

[Issue 2773] ICE(go.c) array assignment through a pointer, only with -O.

[d-bugmail]

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


Don clugd...@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.




--- Comment #5 from Don clugd...@yahoo.com.au  2009-05-20 06:49:00 PDT ---
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: ---