p5pRT
commented
24 years ago From tecmpl1@triton.ca.boeing.com
Created by tecmpl1@triton.ca.boeing.com
I have been trying to get perl 5.6 installed and tested on our Cray T916. I normally expect to have a few problems with a new version of perl because of the rarity of this machine\, but 5.6 has been much more difficult than previous versions.
I started by building perl 5.6 right out of the box with all the recommended defaults. The build ran fine. I did a make test and a perl harness. The summary from perl harness was as follows:
Failed Test Status Wstat Total Fail Failed List of failed ------------------------------------------------------------------------------- lib/dprof.t 18 1 5.56% 18 op/64bitint.t 48 7 14.58% 23\, 28\, 31\, 34-37 op/bop.t 30 5 16.67% 8-12 op/misc.t 62 1 1.61% 3 op/pack.t 156 1 0.64% 10 op/runlevel.t 20 8 40.00% 2-7\, 10\, 14 pragma/utf8.t 1 256 ?? ?? % ?? pragma/warnings 370 1 0.27% 289 8 tests and 79 subtests skipped. Failed 8/236 test scripts\, 96.61% okay. 24/10025 subtests failed\, 99.76% okay.
That was a bit discouraging\, but I pressed on.
The failures in dprof.t\, runlevel\,t\, utf8.t\, and warnings.t all proved to be caused by a single problem in pp_ctl.c. There appears to be a bug in either the c compiler or the c library. In routine S_docatch\, the variable cursi is declared volatile and defined at line pp_ctl.c:2566. cursi is then tested at line pp_ctl.c:2586. It should still have the same value even if S_docatch has been re-entered via a longjmp. Well\, it doesn't. With normal optimization\, cursi is stored in a register. This register should be saved and restored across the setjmp/longjmp. Rather than reduce the optimization for all of perl or modify the makefile to do pp_ctl.c differently\, I fixed the problem by declaring cursi at the front of the module. This causes it to be stored in memory. I need to submit a problem report to Cray\, but I'm not optimistic I can reproduce the problem in a reasonably-sized test case.
Next I noticed that some of the 64-bit tests were failing because of precision problems related to converting to floating point and then back to integer. Adding use integer helped in some cases but caused other tests to be wildly wrong. This is because the otimization known as fastmd restricts integer values to 46 bits. Changing the compiler optimization from -O1 to -h nofastmd fixed this. I would like to recommend that the hints file be changed to reflect this.
After changing to nofastmd\, I was able to get all of 64bitint.t to run correctly by adding use integer to tests 23\, 24\, 28\, and 31. This seems entirely reasonable.
After making these changes\, I rebuilt perl and reran perl harness. The resulting summary was
Failed Test Status Wstat Total Fail Failed List of failed ------------------------------------------------------------------------------- op/bop.t 30 1 3.33% 12 op/misc.t 62 1 1.61% 3 op/pack.t 156 1 0.64% 10 8 tests and 79 subtests skipped. Failed 3/236 test scripts\, 98.73% okay. 3/10085 subtests failed\, 99.97% okay.
My analysis of the remaining failures is as follows:
Test 12 in bop.t is
print ((($cusp >> 1) == ($cusp / 2) && do { use integer; $cusp >> 1 } == -($cusp / 2)) ? "ok 12\n" : "not ok 12\n");
($cusp is 1 \<\< 63)
All I can say about this is I got the test to run by extending the scope of use integer:
print ((($cusp >> 1) == ($cusp / 2) && do { use integer; ($cusp >> 1) == -($cusp / 2)}) ? "ok 12\n" : "not ok 12\n");
Test 3 in misc.t is
use integer; $cusp = ~0 ^ (~0 >> 1); $\, = " "; print +($cusp - 1) % 8\, $cusp % 8\, -$cusp % 8\, ($cusp + 1) % 8\, "!\n";
This seems to be assuming sign extension; i.e.\, $cusp == 0. Well\, a Cray T90 doesn't do sign extension. Instead of the expected result of
-1 0 0 1
I get
7 0 0 -7
My suggestion is to rewrite the test so it doesn't assume sign extension. This may also have something to to with the failure of bop.t test 12.
Test 10 in pack.t is
# check 'w' my $test=10; my @x = (5\,130\,256\,560\,32000\,3097152\,268435455\,1073741844\, '4503599627365785'\,'23728385234614992549757750638446'); my $x = pack('w*'\, @x); my $y = pack 'H*'\, '0581028200843081fa0081bd8440ffffff7f848080801487ffffffffffdb19caefe8e1eeeea0c2e1e3e8ede1ee6e';
print $x eq $y ? "ok $test\n" : "not ok $test\n"; $test++;
The problem concerns the 9th elemnt of @x\, '4503599627365785'. This is getting converted to floating point and back to integer. The number is now 4503599627365776. The encoding is being done correctly\, but it has the wrong argument. The result is ....fffffdb10..... instead of .....fffffdb19..... Some code in pp_pack which caused the second branch of 'w' processing ('decimal string arithmetics') to be used has been removed. The first branch (pp.c:4752 - 4763) is now being used instead. The test at pp.c:4745 - 4751 needs to be modified somehow to reinstate the previous behavior.
As an aside\, I tried enabling long doubles. This resulted in many additional test failures. The precision in many cases seemed to be worse rather than better. I may tackle this problem at some point in the future.
Migrated from rt.perl.org#3102 (status was 'resolved')
Searchable as RT3102$