Unicoss 10.0.0.6 and perl 5.6.0

[p5pRT]

Migrated from rt.perl.org#3076 (status was 'resolved')

Searchable as RT3076$

[p5pRT]

From payner@ncisv11.NCIFCRF.GOV

Created by payner@ncifcrf.gov

I compiled perl 5.6 and it mostly works. However the make test
gives some errors​:

op/64bitint..........FAILED at test 23
op/bop...............FAILED at test 12
op/misc..............PROG​:
use integer;
print +($cusp - 1) % 8, $cusp % 8, -$cusp % 8, ($cusp + 1) % 8, "!\n";
EXPECTED​:
-1 0 0 1 !
GOT​:
7 0 0 -7 !
FAILED at test 3

op/pack..............FAILED at test 10

Failed 5 test scripts out of 230, 97.83% okay.

How important are these failures ? Has anyone ported perl 5.6
to unicos 10.0.0.6 ?

Perl Info

Flags:
    category=core
    severity=low

This perlbug was built using Perl v5.6.0 - Fri Apr  7 09:37:03 EDT 2000
It is being executed now by  Perl 5.00503 - Wed Jan 26 13:17:54 EST 2000.

Site configuration information for perl 5.00503:

Configured by miaskiew at Wed Jan 26 13:17:54 EST 2000.

Summary of my perl5 (5.0 patchlevel 5 subversion 3) configuration:
  Platform:
    osname=unicos, osvers=10.0.0.6, archname=CRAY_SV1-unicos
    uname='sn3217 ncisv11 10.0.0.6 roo.0 cray sv1 '
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=undef useperlio=undef d_sfio=undef
  Compiler:
    cc='cc', optimize='-O0', gccversion=
    cppflags='-I/usr/local/include'
    ccflags ='-I/usr/local/include'
    stdchar='unsigned char', d_stdstdio=define, usevfork=false
    intsize=8, longsize=8, ptrsize=8, doublesize=8
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
    alignbytes=8, usemymalloc=n, prototype=define
  Linker and Libraries:
    ld='ld', ldflags =' -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib
    libs=-lnsl -lmalloc -lc -lcrypt
    libc=/lib/libc.a, so=none, useshrplib=false, libperl=libperl.a
  Dynamic Linking:
    dlsrc=dl_none.xs, dlext=none, d_dlsymun=undef, ccdlflags=''
    cccdlflags='', lddlflags=''

Locally applied patches:
    


@INC for perl 5.00503:
    /usr/local/lib/perl5/5.00503/CRAY_SV1-unicos
    /usr/local/lib/perl5/5.00503
    /usr/local/lib/perl5/site_perl/5.005/CRAY_SV1-unicos
    /usr/local/lib/perl5/site_perl/5.005
    .


Environment for perl 5.00503:
    HOME=/users/primgr/payner
    LANG (unset)
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/opt/craysoft/nqe/bin:/opt/ctl/bin:/opt/ctl/craylibs/3.3.0.0/bin:/bin:/usr/bin:/usr/ucb:/usr/lbin:/usr/local/bin:/etc:/usr/local/bin:/usr/bin/X11::/etc:/usr/local/bin:/usr/bin/X11:
    PERL_BADLANG (unset)
    SHELL=/bin/csh

[p5pRT]

From [Unknown Contact. See original ticket]

Robert Payne <payner@​ncisv11.NCIFCRF.GOV> wrote

op/64bitint..........FAILED at test 23
op/bop...............FAILED at test 12
op/misc..............PROG​:
use integer;
print +($cusp - 1) % 8, $cusp % 8, -$cusp % 8, ($cusp + 1) % 8, "!\n";
EXPECTED​:
-1 0 0 1 !
GOT​:
7 0 0 -7 !
FAILED at test 3

op/pack..............FAILED at test 10

Failed 5 test scripts out of 230, 97.83% okay.

How important are these failures ?

At least two of them are bugs in the tests.

op/bop test 12​:
This is testing the >> operator on a negative LHS under "use integer",
and assuming that you get sign bit propagation. But under "use integer"
you get "what the underlying C happens to do", and the C standard
explicitly leaves undefined whether sign propagation occurs in this case.

op/misc test 3​:
Similarly, this is using the >> operator under "use integer" to
calculate the constant $cusp for the test. So on most platforms
it's getting a value of 0 for $cusp; probably not what the test designer
intended. Also, it's checking the result of the % operator with
negative arguments; this is also not defined by the C standard.

Two additional questions about this test​:
a) The "use integer" was added recently (between 5.5.660 and 5.6.rc1).
  Why? What exactly is this test trying to exercise?
b) In view of the rubric at the top of t/op/misc.t

# NOTE​: Please don't add tests to this file unless they *need* to be run in
# separate executable and can't simply use eval.

  why is this test where it is?

The attached patch fixes[*] these two tests. Whether it's the "right"
fix depends on the answers to the above questions.

[*] Of course, I've only checked it on platforms I have access to;
  someone else will need to check it on Unicos.

Mike Guy

Inline Patch

--- ./t/op/bop.t.orig	Tue Apr 18 17:34:38 2000
+++ ./t/op/bop.t	Tue Apr 18 17:14:33 2000
@@ -39,7 +39,7 @@
 	do { use integer; 1 << ($bits - 1) } == -$cusp)
        ? "ok 11\n" : "not ok 11\n");
 print ((($cusp >> 1) == ($cusp / 2) &&
-	do { use integer; $cusp >> 1 } == -($cusp / 2))
+	do { use integer; abs($cusp >> 1) } == ($cusp / 2))
        ? "ok 12\n" : "not ok 12\n");
 
 $Aaz = chr(ord("A") & ord("z"));
--- ./t/op/misc.t.orig	Tue Apr 18 17:34:38 2000
+++ ./t/op/misc.t	Tue Apr 18 17:57:47 2000
@@ -59,12 +59,12 @@
 EXPECT
 a := b := c
 ########
-use integer;
 $cusp = ~0 ^ (~0 >> 1);
+use integer;
 $, = " ";
-print +($cusp - 1) % 8, $cusp % 8, -$cusp % 8, ($cusp + 1) % 8, "!\n";
+print +($cusp - 1) % 8, $cusp % 8, -$cusp % 8, 8 | (($cusp + 1) % 8 + 7), "!\n";
 EXPECT
--1 0 0 1 !
+7 0 0 8 !
 ########
 $foo=undef; $foo->go;
 EXPECT

End of patch

[p5pRT]

From @jhi

: Two additional questions about this test​:
: a) The "use integer" was added recently (between 5.5.660 and 5.6.rc1).
: a Why? What exactly is this test trying to exercise?

I made the change when I made the bitops to be 64-bit where
applicable, because then the integerless version no more worked where
sizeof(UV) >= sizeof(NV), because then numbers having too many
high-end bits on couln't be stored in a NV. Your patch seems to be
okay on such platforms, such as Tru64 (aka DIgital UNIX0.
What the test was orginally trying to exercise, I no more exactly
remember (hey, maybe we should *gasp* start commenting the *.t files).
Seems to be testing the modulus operator at the outer IV/UV limits?

It's a pity that the behavior of % is so poorly (yeah, as poorly as in
C, I know we are trying to ape C, but aping also mistakes is carrying
it too far) defined in Perl. (Ditto for << and >>, right? IIRC
shifting by more than the bit width, or shifting by zero or by a
negative number are not defined, either.)

[p5pRT]

From [Unknown Contact. See original ticket]

Jarkko Hietaniemi <jhi@​iki.fi> wrote

It's a pity that the behavior of % is so poorly (yeah, as poorly as in
C, I know we are trying to ape C, but aping also mistakes is carrying
it too far) defined in Perl.

That's a bit unfair to Perl's documentation. Actually % is very
precisely defined. It's just that in the "use integer" case, it's
defined by reference to the underlying library, and defining that isn't
Perls problem. You can't have a more precise definition unless you
change the meaning of "use integer".

                          \(Ditto for \<\< and >>\, right? IIRC

shifting by more than the bit width, or shifting by zero or by a
negative number are not defined, either.)

Here perlop is a bit minimal.

Mike Guy