I think you're really on to something, as I'm seeing similar things with
a 32-bit perl on 64-bit linux box.
Philippe
PS: the 'other' setup:
osname=linux, osvers=2.6.5-7.97-smp, archname=x86_64-linux
uname='linux sunfire 2.6.5-7.97-smp #1 smp fri jul 2 14:21:59 utc
2004 x86_64 x86_64 x86_64 gnulinux '
config_args='-Dprefix=/WORK/philippe/Tools/Perl
-Dhtml1dir=/WORK/philippe//Tools/Perl/html
[EMAIL PROTECTED] -Dcc=gcc -m32 -d -e'
Nicholas Clark wrote:
>
> On Mon, Nov 13, 2006 at 09:13:56AM +0100, Philippe Schaffnit wrote:
> > gcc -mabi=64 -O3 -c -D_BSD_TYPES -D_BSD_TIME -mabi=64
> > -fno-strict-aliasing -I/usr/local/include -DLANGUAGE_C
> > -I/usr/local_people/Philippe/Perl/lib/perl5/5.8.8/IP35-irix/CORE sha1.c
>
> Are you in a position to test build PAR against a 32 bit Perl on IRIX?
> If so, does it pass tests?
> It may be that there's some C code in PAR that is subtly buggy because it's
> relying on what's actually undefined behaviour. I've got bitten by how SGI's
> compiler in 64 bit mode (quite correctly) behaves when doing signed integer
> overflow on 32 bit types.
>
> Nicholas Clark
