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/a528908271c678360d2d8ca232c178e7cdd340b4/missing/dtoa.c#L3411
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/a528908271c678360d2d8ca232c178e7cdd340b4/vsnprintf.c#L529
- cvt
https://github.com/ruby/ruby/blob/a528908271c678360d2d8ca232c178e7cdd340b4/vsnprintf.c#L1229
- 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
_______________________________________________
ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org
To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/ruby-sig@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
