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

--- Comment #1 from Johannes Pfau <johannespfau@gmail.com> 2012-09-25 09:24:52 UTC ---
Created attachment 7
  --> http://gdcproject.org/bugzilla/attachment.cgi?id=7
system / compier information

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

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

--- Comment #2 from Iain Buclaw <ibuclaw@gdcproject.org> 2012-09-25 20:48:27 UTC ---
You may think so, but this is actually not a bug, just a little known example of an x86-specific quirk.

In D functions (thus, extern D) - everything should be evaluated left to right (LTR).  And I am pretty confident for most cases, GDC gets this correct in the codegen despite pulling an arm or two in the process to get it done.

For extern C functions you are left up to the order of which the underlying architecture pushes arguments on the stack.  As it just so happens, x86/x86_64 is right to left (RTL), aka PUSH_ARGS_REVERSED.

So expecting BCA makes sense as:
A()[] = B()[] + C()[];

Gets turned into:
_arraySliceSliceAddSliceAssign_f(A[], C[], B[]);

Hence why it asserts that the result is "BCA".


However, ARM pushes arguments on the stack LTR, so we should instead expect the result of the array operation to be "ACB"

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

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

Alex Rønne Petersen <alex@lycus.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |alex@lycus.org

--- Comment #3 from Alex Rønne Petersen <alex@lycus.org> 2012-09-26 08:03:04 UTC ---
Just leaving some IRC logs here to record my opinion on the matter:

20:52:37 < Zor> ibuclaw: in my opinion, the language should make strong
guarantees about this stuff that compilers must
                follow, regardless of arch quirks
20:53:05 < ibuclaw> extern(D) makes strong guarantees.
20:53:28 < ibuclaw> extern(C) doesn't, which is why the testcase is fairly
bogus.
20:55:44 < Zor> ibuclaw: I don't see why the compiler can't make the same
guarantees about extern (C) functions too
20:56:48 < Zor> ibuclaw: the compiler would have to do some extra work to
ensure LTR evaluation order, but that
                shouldn't be impossible
20:58:08 < Zor> ibuclaw: I especially think it's worth looking into because
there's nothing even mentioning C
                linkage/ABI in this piece of D code, which makes the gotcha
even more ridiculous
20:58:57 < ibuclaw> Zor, the problem is there would be code out there that
relies on the already existing behaviour,
                    sadly enough.
20:59:28 < Zor> yes, but there's no point in caring about that
20:59:41 < Zor> TDPL says left-to-right, always
20:59:53 < Zor> it'll break code, but we need to clean up the mess sooner
rather than later
21:00:51 < ibuclaw> Zor, does it explicitly say 'all functions, even extern(C)'
? :^)
21:01:34 < Zor> All arguments are evaluated left to right
21:01:34 < Zor> before fun gets invoked.
21:01:50 < Zor> that's in the description of the function call operator
21:01:59 < Zor> so it's regardless of linkage, I'd say
21:02:28 < Zor> besides, I think code relying on RTL evaluation will be very
rare
21:02:34 < Zor> LTR is what people intuitively expect

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

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

--- Comment #4 from Johannes Pfau <johannespfau@gmail.com> 2012-09-27 17:36:57 UTC ---
For reference: Related discussion in D newsgroup: http://forum.dlang.org/thread/bniaxycuguviwfdtojzf@forum.dlang.org

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