Re: [ANN] Lua 5.4.0 now available

[Andrew Gierth <andrew@...>]

>>>>> "Joseph" == Joseph C Sible <josephcsible@gmail.com> writes:

 >> That is one more point in favor of a compiler bug. After this print,
 >> numbuff is simply passed as an argument to tostringbuff, and
 >> suddenly its value changes from 0x7ffe557f6150 (or 0x7fffffffd850,
 >> in the trace you sent earlier) to 0x3ff0000000000000.

 Joseph> Looks like a compiler bug to me too. Here's a minimized example:
 Joseph> https://godbolt.org/z/RMc3RX

 Joseph> I reported it to GCC's bug tracker:
 Joseph> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96040

I think I see what's happening here, but I don't think I have an account
on the gcc bug tracker to post it there (feel free to forward this).
It's not (I think) a confusion over how many arguments the specialized
tostringbuff.part.0.isra function has, but rather over the type, or
equivalently the register allocation, for the first parameter.

The callsite is putting num->value_.n into %rdi, and &space into %rsi,
as if the function were declared as taking (long long v, char *buf)
rather than (double v, char *buf) which would require that num->value_.n
be placed in %xmm0 and &space into %rdi.

But the code of the function itself is assuming that the incoming values
are in %xmm0 and %rdi - %xmm0 is not touched because it's already in the
right place for the snprintf call, while %rdi is left as the first arg
to snprintf. The value 0x3ff0000000000000 is of course 1.0 as a double,
which naturally does not work well as a pointer so it blows up.

-- 
Andrew.