--- Comment #1 from Don <> 2010-04-28 20:55:10 PDT ---
This patch also fixes:
bug 2549 Segfault on array multiplication.
bug 3066 Array operation without a slice as the lvalue accepted, bad codegen
bug 3817 Array op: wrong error message

The root cause is that array operations which require memory allocations are
not handled in the front-end. At entry to the backend, no array ops should
still exist inside expressions. Currently, only arr[]+arr[] and arr[]-arr[]
generate error messages; all other cases get passed through to the backend,
resulting in bad code generation or an ICE.
The error messages just need to be expanded to cover the other cases.
(Note that when the front-end supports these types of operations, this test is
still useful -- it acts as an assert for the backend).

e2ir.c, around line 2098. AddExp, MinExp catch errors, but the other array ops
They all need to catch var*arr, arr*var as well as arr*arr.

(The var+arr check is required for the example in the comments in 3066).

The error message is confusing (this is bug 3817), for all of them should be
something like:
Should be "Array operation %s not implemented (requires memory allocation)"

NegExp needs to be treated, as well. For each of AddExp, MinExp, MulExp,
the code should be of this form (with only the OPmul line changing).

elem *MulExp::toElem(IRState *irs)
{   elem *e;
    Type *tb1 = e1->type->toBasetype();
    Type *tb2 = e2->type->toBasetype();

    if ((tb1->ty == Tarray || tb1->ty == Tsarray) ||
        (tb2->ty == Tarray || tb2->ty == Tsarray)
        error("Array operation %s not implemented (requires memory
allocation)", toChars());
        e = el_long(type->totym(), 0);  // error recovery
        e = toElemBin(irs, OPmul);
    return e;

Configure issuemail:
------- You are receiving this mail because: -------

Reply via email to