Fix the weird-ass crash on AArch64

[LemonBoy]

What

It turns out that adding our own implementation of __addtf3 uncovered a (painfully obvious in hindsight) bug in another unrelated builtin.

How

The main clue leading to this discovery was this piece of ASM:

mov  x19, x1                                
bl   0xffffa3b8e320 <__extendsftf2@plt>     
str  q0, [sp, #48]                          
mov  x0, x21                                
bl   0xffffa3b865b0 <__floatunditf@plt>     
ldr  q2, [sp, #48]                          
mov  v1.16b, v2.16b                         
str  q2, [sp, #80]                          
bl   0xffffa3b8e0b0 <__divtf3@plt>          
str  q0, [sp, #48]                          
mov  x0, x19                                
bl   0xffffa3b865b0 <__floatunditf@plt>     
str  q0, [sp, #64]                          
ldr  q4, [sp, #48]                          
mov  v1.16b, v4.16b                         
bl   0xffffa3b87fc0 <__letf2@plt>           
cmp  w0, #0x0                               
ldr  q6, [sp, #64]                          
ldr  q2, [sp, #80]                          

Can you spot the error? No? Because there's no error!
This is the code from libstdc++'s Prime_rehash_policy::need_rehash that's completely correct and indeed works just fine when linked against libgcc or LLVM's compiler-rt.

What prompted me to look at __floatundidf was this piece of code:

str  q0, [sp, #48]                          
mov  x0, x19                                
bl   0xffffa3b865b0 <__floatunditf@plt>    

As you can see it only setups x0, the first register used for passing arguments, and, being the xN registers 64-bit wide, that meant x1 was actually filled with hot garbage! (Remember that x0-x7 are scratch registers and are not saved across calls).

The fix is easy peasy, the big question looming over us is: are there any other mistakes like this?

Proudly closes #4822

[andrewrk]

👏 👏 👏 👏 👏 👏