On 09/26/2012 10:11 AM, Walter Bright wrote:
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.
On x86. It is unspecified, therefore different compilers on different
architectures do it in different ways.
So we should be all right by simply
defining that D do it that way for C functions.
I disagree. Why should the calling convention have an impact on code
semantics? The code reads LTR, therefore evaluation should consistently
be LTR.
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.
...
There is no such thing. C and C++ get evaluation order thoroughly wrong.
