Vít Ondruch wrote on 2023/01/18 23:45:
Dne 17. 01. 23 v 15:48 Mamoru TASAKA napsal(a):
> Vít Ondruch wrote on 2023/01/04 21:13:
>>
>> Dne 04. 01. 23 v 8:55 Mamoru TASAKA napsal(a):
>>> Vít Ondruch wrote on 2023/01/03 23:28:
>>>> Hi everybody,
>>>>
>>>> Ruby 3.2 is out and it is time for Ruby mass rebuild. First of all,
I'd like to thank to Mamoru for the preparation and lot of fixes all around. I really
appreciate that. Due to this, I feel we are in better shape then we ever was and we can
start with rebuld, therefore I have requested side-tag:
>>>>
>
> Note that as you are watching koschei so I guess you have already
> noticed this, however currently ruby is reproducible FTBFS on ppc64le
> due to the below:
>
> 1) Failure:
> TestSprintf#test_float_hex
[/builddir/build/BUILD/ruby-3.2.0/test/ruby/test_sprintf.rb:299]:
> <"-0x0p+0"> expected but was
> <"-0x1p-1537">.
Yeah, I have noticed this. I hope it disappears the same way it appeared :D
On second thought, it might very well be that I have analyzed something similar earlier
(probably quite some time ago) and it was related to specific CPU features. I'll try
to remember what was the specific case.
Well, the above test failure on ppc64le is still reproducible with
gcc-13.0.1-0.1.fc38.ppc64le.
The simple reproducer is
$ ruby --disable-gems -e 'puts sprintf("%a", -0.0)'
returns "-0x1p-1537", which must be "-0x0p+0".
As far as I am looking into this, what is sure that the following comparison:
https://github.com/ruby/ruby/blob/a528908271c678360d2d8ca232c178e7cdd340b...
is failing when d is actually -0.0: when d is -0.0, (d == 0.0) must pass.
What is difficult here is that:
* Extracting this hdtoa code only, compiling on ppc64le and executing unit test using
hdtoa function does not reproduce this failure (i.e. (d == 0.0) passes).
* Looking at disassembled code of libruby.so.3.2 on ppc64le, due to LTO,
- BSD_vfprintf
https://github.com/ruby/ruby/blob/a528908271c678360d2d8ca232c178e7cdd340b...
- cvt
https://github.com/ruby/ruby/blob/a528908271c678360d2d8ca232c178e7cdd340b...
- and hdtoa
are unified, hdtoa code is divided by input double value cases, and actually
it looks like that the above (d == 0.0) comparison is optimized away....
* So disabling LTO actually makes the original test pass.
So I suspect gcc-13.0.1-0.1.fc38.ppc64le LTO on ppc64le is broken (althogh there may be
some
possibility that ruby code contains some UB...), but as this is related to 3 functions,
it may difficult to report to gcc developers....
Mamoru