Re: [ANN] Lua 5.4.0 now available
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
- Subject: Re: [ANN] Lua 5.4.0 now available
- From: Andrew Gierth <andrew@...>
- Date: 2020年7月03日 00:33:16 +0100
>>>>> "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.