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

[d-bugmail at puremagic.com]

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


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

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


--- Comment #8 from Don <clugdbug at 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: -------