On Mon, 9 Feb 2009, Reini Urban wrote:
> 2009/2/9 Andrew Dougherty <dough...@lafayette.edu>:
> >> --- tools/dev/mk_native_pbc (revision 36480)
> >> +++ tools/dev/mk_native_pbc (working copy)
> >> @@ -1,32 +1,130 @@
> > > #!/bin/sh
> >>
> >> -# generate t/native_pbc_{1,2}.pbc
> >> -# this should be run on i386 systems to regenerate the first two
> >> -# native tests
> >> -# NOTE: This will need a perl compiled with long double support
> >> +# generate t/native_pbc/_{1,2}.pbc
> >
> > Actually, that hasn't been true for a while.
> >
> > perl Configure.pl --floatval='long double'
> >
> > should be all that is needed. I do note, however, that this will
> > pick the wrong printf format string for floats. The patch in TT #294
> > fixes that.
>
> I saw that fix.
> On cygwin the old comment is true. cygwin perl supports no hugefloat
> (long double),
> but use64bitint, and perl Configure.pl --floatval='long double' fails in JIT.
> src/jit/i386/core.jit:921:75: macro "emitm_fldt" requires 6
> arguments, but only 5 given
> perl Configure.pl --floatval='long double' --jitcapable=0 passes.
But I don't see how that has anything to do with whether the perl used to
run Configure.pl has 'long double' or not. Or, phrased differently, that
same JIT error occurs on x86 whether or not the perl used to run
Configure.pl has long double support or not. Hence I conclude that having
a perl compiled with long double support isn't necessary.
It does look like there's a JIT bug somewhere -- probably, Configure.pl
should simply refuse to try JIT if you insist on building with
non-standard data types, but that's a different issue.
--
Andy Dougherty dough...@lafayette.edu
