On Wednesday, 26 September 2012 at 08:12:16 UTC, 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. 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.
Speaking as a generalisation, no that is not true. C functions
for x86/x86_64 all seem to evaluate their args right-to-left.
However - and this may be different from compiler to compiler -
GCC at least does left-to-right evaluation for everything else
(ARM, SPARC, etc) because that is the order that arguments are
pushed onto the stack for those architecture backends.
If right-to-left should be the strict standard to follow for
extern(C), then document this behaviour as part of the
specification, and I'll implement it. :~)
Regards
Iain
