develooper Front page | perl.perl5.porters | Postings from January 2001

Re: [ID 20010118.017] Not OK: perl v5.7.0 +DEVEL8465 on i686-linux-ld 2.2.13

Thread Previous | Thread Next
Nicholas Clark
January 19, 2001 10:47
Re: [ID 20010118.017] Not OK: perl v5.7.0 +DEVEL8465 on i686-linux-ld 2.2.13
Message ID:
On Fri, Jan 19, 2001 at 12:58:13AM +0100, wrote:
> On Thu, Jan 18, 2001 at 11:13:42PM +0000, Nicholas Clark wrote:
> > 
> > Thanks. Now I'm more confused. I think it is failing in this bit of code in
> > op_int in pp.c
> > 
> > #if defined(HAS_MODFL) || defined(LONG_DOUBLE_EQUALS_DOUBLE)
> >                   (void)Perl_modf(value, &value);
> > #else
> >                   double tmp = (double)value;
> >                   (void)Perl_modf(tmp, &tmp);
> >                   value = (NV)tmp;
> > #endif
> >                   SETn(value);
> > 
> > 
> > Unfortunately I deleted the vast majority of your OK/NOK messages.
> > Were you only seeing the failures for op/int.t when configuring without
> > 64 bit IVs, and with long doubles?
> Indeed. -Duselongdouble gives these failures, unless either -Duse64bitall
> or -Duse64bitints is present.
> > Do you have earlier versions of perl (either bleadperl pre patch 8000 or so,
> > or anything earlier - ie before the IVUV changes) built with this
> > configuration and the same compiler, that you could easily run the new
> > op/int.t on? If so, could you do so and send the results.
> I don't have them around, but I build quite a number of bleedperls
> in August/September, and as far as I can remember, I didn't get any
> op/int.t errors. And this was with the same compiler and configuration
> options as back then.

No failures because tests 8 to 14 were only added this week.
I wasn't expecting them to fail on any previous version - they were added
because one catches a bug discovered in the IVUV preserving code, and
the others test edge cases that might be problems, and (the two that fail)
things that should not be problems (values too large for 32 bit IVs) but
were never tested before.

> > Am I justified in suspecting a compiler issue here?
> I'm not qualified to answer that question.

Tricky. In that currently you seem to be the only person with a machine
setup which can replicate the problem.

The oldest thing I've got is gccversion='2.95.2 20000220 (Debian GNU/Linux)'
libc=/lib/ and it passes all 14 tests

Would it be possible for you to build release perl 5.7.0 with long doubles
and no 64 bit ints, run the current 14 test op/int.t and send the results?
My hunch is that you will see the same failures on 5.7.0, and possibly
also 5.6.0 (if that allows long doubles)

Nicholas Clark

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About