Perl 5.34 fails to build with GCC 12.0.1 on ppc64le (ext/XS-APItest/t/printf.t) #19373
Comments
|
That's curious - I think it should be equivalent to this C code: Does that work on the affected system? It sounds likely to be a library or compiler bug. |
|
@hvds the output is |
|
That is weird, because @hvds 's snipplet is exactly what the second test does internally. Did you compile it with the same flags and such? |
@jplesnik, that It looks to me that either perl itself has not correctly recognized the long double format, or I would actually install Inline::C to facilitate the probing of this perl's handling of long double. UPDATED: Original script failed to link to -lm, which adversely affected the result. For perl-5.35.4, on my ppc64be machine (longdblkind=6, nvtype='double'), that outputs: What do you get ? Correct output (if I'm thinking correctly) on your machine would be: But, given the strange test failure, I wouldn't be surprised if that hex output you get will begin with 16 zeros. Afterthought: which, for you, should output: |
If that was the case the second test wouldn't also fail |
|
On Fri, Jan 28, 2022 at 1:07 PM Leon Timmermans ***@***.***> wrote:
or PERL_PRIfldbl is not defined appropriately.
If that was the case the second test wouldn't also fail
Yes ... and yet the Configure script (which I've just now looked at) seems
solid to me, and if it determines that the longdblkind is "7", then I can't
see how that could be incorrect.
So, we might need to explain how "%5.3Lf" formatting is working as expected
in the pure C environment, but not in XS-APItest.xs ?
|
I've just noticed that perl reports that it was built using a different version of gcc: I don't know if that has any connection to the problem and/or its solution |
|
The system |
Ok ... this perl that was built with gcc-12.0.1 is reporting that the long double is actually the "IEEE" 754 128-bit little endian long double. I'd still like to get some idea of the internal structure of this long double. If it is, indeed, the "IEEE" 754 128-bit little endian long double, then it should output: |
|
The output is like you expected |
It is indeed IEEE 128-bit floating point. Fedora is transitioning the default long double for ppc64le. It's the first distro doing this. |
@tuliom, I wonder if XS-APITest.xs is aware of this. (I think it would be, so long as it has been compiled with the perl that's executing the test scripts.) The thing that hits me is that if a program that's expecting a longdblkind of 7 receives 000000000000000000000000000c1004, then it's going to report that value as zero - because it thinks it's receiving a doubledouble of (0, 2.21875), which is actually an invalid doubledouble for that platform. And I'm wondering whether that's precisely what's happening in @jplesnik's case .... but it's a little hard to see from here ;-) I think the next thing for @jplesnik to do is to now cd to the ext/XS-APItest folder and execute t/printf.t using the very same perl executable (with a longdblkind of 1), by running: @jplesnik, what happens with that ? |
If you want to look at complete build log from ppc64le, please check https://jplesnik.fedorapeople.org/perl-gcc12/ |
@sisyphus That's correct. However, as Fedora is in the middle of the long double migration, I think the questions that we have to answer in order to continue moving with the migration are:
|
Sorry - I've probably allowed the the difference in the perl configurations that have been presented here to throw me more than it should have. There's nothing in the build log, to which @jplesnik has just provided a link, that helps me to understand what's going wrong. (There might of course be clues in there that I haven't picked up on.) As I said, I'd want to use Inline::C to probe what's happening. I guess you could also hack at XS-APItest.xs so that it provides additional diagnostics. Or even just hack ext/XS-APItest/t/printf.t to check some other long double values, and see if those results confirm the hypothesis that the IEEE 128-bit little endian is being treated as a doubledouble. ( To my mind, it is only an hypothesis at this stage. Select valid doubledouble values that also have valid internal structure for the IEEE 128-bit le type ... and see which one is reported by print_long_doubleL() ... assuming it will report either one or the other ;-) If you try to build this perl with the addition of the -Duselongdouble switch, you'll possibly get a better idea of what's going awry. (There's not a lot of probing of the 'long double' being done when building a perl whose nvtype is 'double'.) @Leont's question "Did you compile it with the same flags and such?" is, I think, somewhat ominous. (Is there a flag that allows this gcc to switch between the 2 long double types ? Or is it hard coded to "IEEE 128-bit little endian" ?) |
Sorry that I did not provide it earlier, the output from Inline::C script is s390x - |
|
@jplesnik , that all looks sane. All I can suggest is that you keep poking at it until you hit some behaviour that's helpful. (Great advice, I know ;-) I'm a bit loath to suggest anything specific, as it will probably just turn out to be a waste of your time. and verify that it really is outputting zeros. (Of course, I feel quite sure that it is.) |
|
@jplesnik, it occurs to me that you should try this Inline::C script which is just a reproduction of the 2 failing routines from APItest.xs: Based on the test failures, one would expect the output to be: However, based on your result with the earlier Inline::C script I provided, one would expect the output to be: What do you get ? |
|
@sisyphus The output of your script is |
|
I don't know why the same code is compiling differently inside ext/XS-APItest than it does inside the Inline::C script. At this point (earlier, in fact) I would want to be sure that the perl source that was used was "fresh" - ie had not been used, cleaned, and then re-used ... and had also not been altered in any way. There's much mention of miniperl during the building of ext/XS-APItest so I would also check that miniperl agrees that longdblkind is 1. which should output the familiar 000000000000000000000000000c1004 . Other than that, I would try hacking APItest.xs to allow us to glean more information about the long double 7.0 that is being seen as 0.000. It's this lack of access to the long double assigned inside APItest,xs that led me to suggest that you try a |
|
@sisyphus I don't know offhand what headers |
|
@hvds I suppose I could make it more explicit - though we do know that, with the Inline::C script, the print_long_doubleL() output of 7.000 is from Similarly, we reason that the reported 0.000 output of print_long_doubleL() in t/printf.t must come from the same Admittedly, neither this Inline::C script nor APItest.xs provides the means to establish whether PERL_PRIfldbl is defined, but I think that the anomaly with the "%5.3Lf" outputs is plenty to ponder over. Inline::C is just an automated building of a perl extension. |
|
I built Perl without Fedora patches and the test failed again. Inline-C output: |
Duh ... sorry, that just unpacks the double 7.0. which should unpack the long double 7.0.
Yes, that's as I expected. UPDATE - What follows here should probably be ignored. I think it's just me getting stuck in the wrong rabbit hole. Can I take you back to your original post. and you also posted the output of running The latter showed a longdblkind of 7. and We know that ./perl has longdblkind of 7. If the "other" perl has longdblkind of 1, then what we're seeing probably makes sense - because you'd be running the XS-APItest tests that have been compiled for a longdblkind of 7, against a perl that has a longdblkind of 1. Do you understand my point ? If you do understand that point, and you're quite certain that it does not apply to your issue, then please tell me so. |
|
I can't reproduce this issue after updating to gcc-12.0.1-0.6.fc36. |
|
@tuliom You are correct, the issue is solved with updated gcc. |
Module:
XS-APItest
Description
On Fedora, the build of perl 5.34 fails with GCC 12.0.1, but only on ppc64le. The failure is caused by test
ext/XS-APItest/t/printf.tSteps to Reproduce
Expected behavior
The test should pass on all architectures.
Perl configuration
The text was updated successfully, but these errors were encountered: