Bug#577016: perl: FTBFS (experimental/sparc): -Duse64bitint problems?

[Niko Tyni]

reopen 577016
retitle 577016 perl: FTBFS (experimental/sparc): -Duse64bitint problems with gcc 4.4
thanks

On Mon, May 10, 2010 at 10:51:30PM +0300, Niko Tyni wrote:

> The discussion on debian-devel has just about sold me on use64bitint
> without uselongdouble for all architectures. 

> However, this bug is a blocker for that and I doubt there's an easy
> way out.

Looks like I was wrong: the easy way out is to use gcc-4.3. Details below.

> The failure in t/op/pow.t is because (in C-speak)
>  (double)pow(2,56) - ((long long)1 << 56) != 0
> on sparc. 

I was confused here. The error is much too big to be just a "normal"
error due to the float conversion.

> smetana% ./perl -Ilib -MDevel::Peek -e '$n=979797979797979797; Dump $n; $n="$n"; Dump $n; printf("%g\n", $n)'

At least this one seems to be a gcc 4.4 bug. Test case:

#include <stdio.h>
int main(void) {
    unsigned long long l = 97979797979797980LL;

    printf("%g\n", (double)l);
    return(0);
}

which gives 2.47804e+17 on gcc-4.4 4.4.2-9 (squeeze) and 4.4.4-1 (sid),
but the more correct 9.79798e+16 with gcc-4.2, gcc-4.3, and gcc-snapshot
20100414-1 (which is gcc 4.5.0 according to the Debian changelog.)

All the tests pass with gcc-4.3 and gcc-snapshot, and as all the
failures with 4.4 seem related to numeric conversions, I suppose they
are essentially the same issue.

I can't see a regression report at gcc.gnu.org, so I'll have to file
one myself.

In the meantime, I'm going to build-depend on gcc-4.3 [sparc].
-- 
Niko Tyni   ntyni at debian.org