[Bug 8] ARM: runnable/arrayop.d fails: Wrong execution order

[gdc-bugzilla at gdcproject.org]

http://bugzilla.gdcproject.org/show_bug.cgi?id=8

--- Comment #10 from Iain Buclaw <ibuclaw at gdcproject.org> 2014-02-13 08:37:03 GMT ---
(In reply to comment #6)
> Iain, do you want to look into this again?
> 
> I read some of the old discussions and the dlang.org pull request and to
> summarize:
> * All functions should be evaluated LTR, even extern(C)
> * Array OPs expect extern(C) functions to be evaluated RTL
> * DMD backend does extern(C) functions RTL
> 
> So in order to fix this, we'd have to evaluate extern(C) function LTR (easy, as
> the hard work has already been done for D functions) and change array ops to
> work with LTR extern(C) functions (needs quite some changes in the frontend and
> druntime, but it's not hard to implement). However, as soon as we change array
> ops in the frontend we break RTL backends(dmd, probably ldc). And fixing these
> backends as well is probably out of scope. We're probably not familiar with
> these and it might be a bad idea from a legal perspective as well?
> 

Not sure about a legal perspective, but if there's something fundamentally
wrong with language semantics and we send a fix upstream to the frontend, I'd
rely on the respective backend devs to be aware of it, and fix the problem
themselves.  It should be easy enough, as all you are doing is caching values
in the codegen before passing.

IMO, I think Andrei would agree that all parameters should be LTR evaluated
regardless of LINK declarations.


To summarise the current situation:

extern(D) int foo(int a, ...);
extern(C) int bar(int a, ...);

foo(i++, i++, i++);   // 1, 2, 3 - Always!
bar(i++, i++, i++);   // 3, 2, 1 - But only on x86!

-- 
Configure bugmail: http://bugzilla.gdcproject.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.