GRRR... always use reply yo all...
--- Forwarded message follows ---
From: Mattia Barbon <[EMAIL PROTECTED]>
To: Simon Cozens <[EMAIL PROTECTED]>
Subject: Re: Tru64 Numeric bug exposed!
Copies to: [EMAIL PROTEC
At 07:40 PM 9/22/2001 +0300, Jarkko Hietaniemi wrote:
>On Sat, Sep 22, 2001 at 05:17:16PM +0100, Simon Cozens wrote:
> > On Sat, Sep 22, 2001 at 04:40:46PM +0100, Simon Cozens wrote:
> > > And now I know why! The branch-fixup section of the assembler's busted:
> >
> > No, that wasn't it. This is i
On Sat, Sep 22, 2001 at 05:31:50PM +0100, Simon Cozens wrote:
> Unfortunately, I do not have the slightest idea why that is failing...
That's failing because the test is way bogus. Mattia, consider yourself
slapped - 4.61168601842739e+18 is only 4611686018427389952.00 on broken
platforms like
On Sat, Sep 22, 2001 at 05:17:16PM +0100, Simon Cozens wrote:
> or is there a saner way to do it?
There is, and I've done it. (removed an assumption in process_opfunc.pl)
Jarkko, please resync; I think you'll find only one test now fails.
Unfortunately, I do not have the slightest idea why that i
On Sat, Sep 22, 2001 at 05:17:16PM +0100, Simon Cozens wrote:
> On Sat, Sep 22, 2001 at 04:40:46PM +0100, Simon Cozens wrote:
> > And now I know why! The branch-fixup section of the assembler's busted:
>
> No, that wasn't it. This is it:
>
> opcode_t *ne_nc_ic(opcode_t cur_opcode[], struct Parro
On Sat, Sep 22, 2001 at 04:40:46PM +0100, Simon Cozens wrote:
> And now I know why! The branch-fixup section of the assembler's busted:
No, that wasn't it. This is it:
opcode_t *ne_nc_ic(opcode_t cur_opcode[], struct Parrot_Interp *interpreter) {
IV return_offset = 5;
if (NUM_REG(cur_opcode[
