Interesting bug :-) .. Looks like our IR builder is not respecting ordering here .. Generated instrs:

        a(0:0) = copy(Fixnum:0)
        a(0:0) = copy(Fixnum:1)
        %v_3 = copy(Array:[a(0:0), Fixnum:1])

So, clearly broken.

This was a "2 bugs for the price of 1" issue :-). See eb3740c

Good job in finding the problem and fixing it so fast. I've confirmed that your fix indeed solves the array construction issue, but it seems that the rabbit hole is even deeper; the same behavior is observed in hash construction as well, for both keys and values.

a = 0
{ a => a, (a = 1) => a } # => { 1 => 1 } (MRI: {0=>0, 1=>1})
{ a => a, a => (a = 2) } # => { 2 => 2 } (MRI: {1=>2})

This has been observed on cc00fd4.

Yes, I was going to audit the other literals and fix them. But, good to get confirmation that others might be broken similarly.

The fix is fairly trivial .. just have to systematically go through all literals and fix the ones that need fixing.

I don't see any other multi-valued literal besides arrays and hashes. If I missed any, please update this issue.

Will check call args and masgns next.

You unearthed a gold mine of a bug here! :) A lot of parallel value construction in many call scenarios are broken. Interesting that this kind of bug never surfaced in mri tests or rubyspec.

a = 10
b = a / (a=10)
p b # prints 1

OR

a = "xyz"
p (a =~ (a = /[x]/)); # throws an exception

@enebo @headius fyi .. so, the real brain dead fix would be to just force all build values to go through 'copyAndReturnValue' and let OptimizeTempVarsPass, LocalOptPass, etc. propagate useless copies (which there will be lots of now). Otherwise, we'll have to look at all parallel value construction in calls, attr assign, etc. and fix up where required (even so, there will be lots of copies).

For the array and hash literal construction cases, after those passes and DCE runs, the output is:

        %t_b_4 = copy({Fixnum:0=>Fixnum:0, Fixnum:1=>Fixnum:1})
        %t_c_5 = copy({Fixnum:1=>Fixnum:1, Fixnum:1=>Fixnum:2})
....
        %t_b_3 = copy(Array:[Fixnum:0, Fixnum:1])

So, those passes will take care of killing useless instrs. but will defer fixing this till we've had a chance to chat about this.

I am resolving this. I covered the cases apparent where we have a list of arguments which must be processed. It is possible some cases were missed (regression spec should cover broad cases known), but if any new cases are found a new issue should be opened.