On 9/26/2012 12:36 AM, Iain Buclaw wrote:
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?
C functions all seem to evaluate their args right-to-left, even though the C
Standard doesn't specify that. So we should be all right by simply defining that
D do it that way for C functions.
It doesn't actually matter what order D does things, we just have to pick one.
And so we might as well pick one that C compilers naturally do anyway.
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.
