Update base/complex.jl for Complex round (Fix/Workaround #10027)

[rickhg12hs]

Adding superfluous tuple splatting to Complex return arguments seems to be an effective workaround for 32-bit system rounding problems for Complex types (#10027).

[StefanKarpinski]

It's weird that that fixed things, but compilers be crazy. How'd you even figure that out?

[rickhg12hs]

@StefanKarpinski : Bottom line, I didn't really figure it out.

I saw that my splatted map work around for round(z::Complex) (from a comment in #10027) wasn't going to translate well for function round{T<:FloatingPoint, MR, MI}(z::Complex{T}, ::RoundingMode{MR}, ::RoundingMode{MI}) (also broken) so I looked at other options. I couldn't figure out how @noinline works (as @vtjnash hinted at), so I just tried the simplest splat I could think of since it seemed that an intermediate result was getting lost/corrupted somehow and perhaps an intermediate tuple might preserve it. Splatting the tuple makes the Complex constructor happy and make test-complex passed on my 32-bit system. Yay! 8-)

N.B.: I have bent screwdrivers from using them as crowbars too.

[staticfloat]

I can also confirm that this fixes things. I say merge this so that the build is not broken, and then we can iterate on a nicer fix.

[timholy]

An interesting fix. There are a lot of tuple-related bugs open now (convertalypse, the --inline=no bugs, etc), I wonder if such shenanigans might help elsewhere too.

CCing @JeffBezanson to see if he has any insight.

[JeffBezanson]

This seems to work by preventing inlining of the Complex constructor. This is probably working around an LLVM bug. Our compiler removes the tuple entirely, of course. This fix is not terribly safe, since we could certainly improve the compiler to be able to inline in this case.

[vtjnash]

iirc, llvm is trying to return this complex number in fp(0) and fp(1). Is it possible that the call to round is corrupting the floating point stack that is being expected by llvm?