Dne 22. 01. 23 v 17:09 Mamoru TASAKA napsal(a):
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 :DOn 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#L3411is 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 hdtoaare 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....
Before noticing this email, I saw the mass rebuild failure and reported this ticket against GCC:
https://bugzilla.redhat.com/show_bug.cgi?id=2163337 I'll put there your comments (I hope you don't mind). Vít
Mamoru _______________________________________________ ruby-sig mailing list -- ruby-sig@lists.fedoraproject.org To unsubscribe send an email to ruby-sig-le...@lists.fedoraproject.orgFedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelinesList 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
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ 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
