On Tuesday, 25 September 2012 at 23:39:39 UTC, Walter Bright
wrote:
On 9/25/2012 3:58 PM, Iain Buclaw wrote:
The problem here is that the array operation A[] = B[] + C[]
gets transformed
into an extern(C) call. And because there's no strict rules
in place over the
order of which it's parameters are evaluated, it could go
either way (LTR, or RTL).
Serious note: This test is bogus as this and similar other
failing tests on
non-x86 platforms are not at all obvious to the users who get
issues. So what
are we to do about it?
D needs to move towards a defined order of evaluation. I
understand that there's a problem when using parts of a C
compiler that feels free to reorder within the C rules. It's
something we have to deal with sooner or later, by either:
1. adjusting the C optimizer so it follows D rules for D code
2. assigning terms to temporaries that are executed in a
specific order by C rules
Indeed, but where does that leave code that gets compiled down to
a extern(C) call?
eg, in the OP, the following is generated:
_arraySliceSliceAddSliceAssign_f(A[], C[], B[]);
To say that all extern(C) calls must follow D rules for D code
(LTR evaluation), is to change the current behaviour of array
operations on it's head, so we'll have to correct a whole lotta
changes in code generation to alter the order of parameters, and
ensure that both DRT supplied and internally generated functions
are corrected for this.
Well... someone's got to do the grizzly bits that no one else
wants to do. :~)
Regards,
Iain.
