On Thu, Aug 03, 2006 at 10:40:09PM -0300, Margarita Manterola wrote:
> Hi!
>
> I've been working with a couple of friends (Damián Viano and Martín
> Ferrari), in trying to fix this bug. We've built perl in an hppa machine
> and use that build to test the following things.
>
> This line:
> ./perl -le 'print unpack("%53c*", pack "c*", -1);'
> can be used to test the problem (it's taken from one of the failing tests).
>
> Doing the normal build ($ debuild), we got these results:
> [EMAIL PROTECTED]:~/perl-5.8.8$ perl -le 'print unpack("%53c*", pack "c*",
> -1);'
> 9.00719925474099e+15
> [EMAIL PROTECTED]:~/perl-5.8.8$ ./perl -le 'print unpack("%53c*", pack "c*",
> -1);'
> 0
>
> After that, we decided to try to build without optimization and stripping
> ($ DEB_BUILD_OPTIONS=noopt,nostrip fakeroot debian/rules binary) and the
> package built successfully ("All tests successful").
>
> Also, we got these results:
> [EMAIL PROTECTED]:~/perl-5.8.8$ perl -le 'print unpack("%53c*", pack "c*",
> -1);'
> 9.00719925474099e+15
> [EMAIL PROTECTED]:~/perl-5.8.8$ ./perl -le 'print unpack("%53c*", pack "c*",
> -1);'
> 9.00719925474099e+15
>
> We didn't really intend this to happen, we only wanted to be able to follow
> the calls to the functions in a gdb session, but this came out as a result
> of the build.
>
> I guess stripping is not at fault, what only leaves the -O0 instead of -O2
> as the possible difference.
>
> Also, in Gentoo perl builds fine with gcc-4.1 in hppa, therefore we suspect
> that the problem is either in a patch that we are applying, or in a patch
> that they are applying and we are not.
>
> We are still working on it. Just wanted to share our progress.
>
It sounds like the gcc optimization is causing various math "optimizations" to
occur. For Perl, however, math optimizations typically cause failures in
t/op/numconvert.t and t/op/pack.t. You may want to test with -O1 to narrow
the possible -f option that may be causing the problems.
Steve Peters
[EMAIL PROTECTED]
