On Wed, 26 Sep 2001, Hong Zhang wrote:
>
> You are using the wrong flag. The expression in second is long long.
> So you should use flag "%llx". Since printf uses vararg, it is
> undefined behavior if there is type mismatch with argument.
Oops. :-)
Andy Dougherty [EMAIL PROTEC
On Wed, 26 Sep 2001, Andy Dougherty wrote:
[Spoiler below]
> On Wed, 26 Sep 2001, Hong Zhang wrote:
>
> > There should be no need. ~0xfff is singed int, which will be signed extended
> > by compilers as needed. Unless you are using a buggy compiler.
>
> Hehehe. Ok. Guess what the following w
You are using the wrong flag. The expression in second is long long.
So you should use flag "%llx". Since printf uses vararg, it is
undefined behavior if there is type mismatch with argument.
Hong
> Hehehe. Ok. Guess what the following will print:
>
> #include
> int main(void) {
> int x
On Wed, 26 Sep 2001, Hong Zhang wrote:
> There should be no need. ~0xfff is singed int, which will be signed extended
> by compilers as needed. Unless you are using a buggy compiler.
Hehehe. Ok. Guess what the following will print:
#include
int main(void) {
int x = 511;
printf("x = %
> > ># > 0xf000 for 64 bit systems. With that changed
>
> > Don't bother. Make the constant be ~0xfff. :)
>
> Umm, are you sure? It's used in an integer context and masked against an
> IV, so you might need an 'int', a 'long', or a 'long long'. I'm unsure
> what type to portably
On Wed, 26 Sep 2001, Dan Sugalski wrote:
> ># > Tru64 core dumps because the value of MASK_CHUNK_LOW_BITS
> ># > 0xf000 for 64 bit systems. With that changed
> Don't bother. Make the constant be ~0xfff. :)
Umm, are you sure? It's used in an integer context and masked against an
I'm not sure this always works. On systems with 32 bit pointers but 64 bit
integers this might produce undesired results...I'm not sure though.
-Original Message-
From: Simon Cozens
To: [EMAIL PROTECTED]
Sent: 9/26/2001 12:15 PM
Subject: Re: Tru64 core dumps
On Wed, Sep 26,
On Wed, Sep 26, 2001 at 06:15:02PM +0100, Simon Cozens wrote:
> On Wed, Sep 26, 2001 at 01:11:56PM -0400, Dan Sugalski wrote:
> > Don't bother. Make the constant be ~0xfff. :)
>
> Oh yeah. *blush*.
All tests successful, 5 subtests skipped.
Yeah!
--
Writing software is more fun than working.
On Wed, Sep 26, 2001 at 01:11:56PM -0400, Dan Sugalski wrote:
> Don't bother. Make the constant be ~0xfff. :)
Oh yeah. *blush*.
--
It would be different if I had an actual ambition to be a corporate pitbull
and be the righteous, noble paperwork warrior tirelessly fighting for the
future vision
On Wed 26 Sep 2001 19:00, Andy Dougherty <[EMAIL PROTECTED]> wrote:
> On Wed, 26 Sep 2001, Brent Dax wrote:
>
> > Configure Man To The Rescue! (Trumpets sound, then stop abruptly.)
> > Now, how do I figure out if we're on a 64-bit system? :^)
>
> ivsize, nvsize, ptrsize, and opcode_t_size (as
At 09:46 AM 9/26/2001 -0700, Brent Dax wrote:
>Simon Cozens:
># On Wed, Sep 26, 2001 at 09:47:08AM -0500, Gibbs Tanton - tgibbs wrote:
># > Tru64 core dumps because the value of MASK_CHUNK_LOW_BITS
># is designed for a
># > 32 bit system. It needs to be changed in the Configure.pl
># script to be
On Wed, 26 Sep 2001, Brent Dax wrote:
> Configure Man To The Rescue! (Trumpets sound, then stop abruptly.)
> Now, how do I figure out if we're on a 64-bit system? :^)
ivsize, nvsize, ptrsize, and opcode_t_size (as yet uncomputed, but will be
needed) come to mind. A '64-bit' system is an impre
On Wed, Sep 26, 2001 at 09:46:42AM -0700, Brent Dax wrote:
> Now, how do I figure out if we're on a 64-bit system? :^)
$Config{ptrsize} == 8;
--
Some people claim that the UNIX learning curve is steep, but at least you
only have to climb it once.
Simon Cozens:
# On Wed, Sep 26, 2001 at 09:47:08AM -0500, Gibbs Tanton - tgibbs wrote:
# > Tru64 core dumps because the value of MASK_CHUNK_LOW_BITS
# is designed for a
# > 32 bit system. It needs to be changed in the Configure.pl
# script to be
# > 0xf000 for 64 bit systems. With th
On Wed, Sep 26, 2001 at 09:47:08AM -0500, Gibbs Tanton - tgibbs wrote:
> Tru64 core dumps because the value of MASK_CHUNK_LOW_BITS is designed for a
> 32 bit system. It needs to be changed in the Configure.pl script to be
> 0xf000 for 64 bit systems. With that changed it works fine.
Tanton - tgibbs; '[EMAIL PROTECTED]'
Sent: 9/26/2001 9:05 AM
Subject: Re: Tru64 core dumps
On Wed, 26 Sep 2001, Simon Cozens wrote:
>On Wed, Sep 26, 2001 at 08:42:52AM -0500, Gibbs Tanton - tgibbs wrote:
>> I'm getting a core dump on Tru64 for stacks.t. Does anyone else g
I also get six, I miscommunicated that one.
-Original Message-
From: Simon Cozens
To: Gibbs Tanton - tgibbs
Cc: '[EMAIL PROTECTED]'
Sent: 9/26/2001 8:42 AM
Subject: Re: Tru64 core dumps
On Wed, Sep 26, 2001 at 08:42:52AM -0500, Gibbs Tanton - tgibbs wrote:
> I'm gett
On Wed, 26 Sep 2001, Simon Cozens wrote:
>On Wed, Sep 26, 2001 at 08:42:52AM -0500, Gibbs Tanton - tgibbs wrote:
>> I'm getting a core dump on Tru64 for stacks.t. Does anyone else get this?
>
>Just the one? I'm getting six of the damned things.
The 01:00 UTC snapshot segfaulted on all tests beca
On Wed, Sep 26, 2001 at 08:42:52AM -0500, Gibbs Tanton - tgibbs wrote:
> I'm getting a core dump on Tru64 for stacks.t. Does anyone else get this?
Just the one? I'm getting six of the damned things.
--
Mohandas K. Gandhi often changed his mind publicly. An aide once asked him
how he could so
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 Thu, Sep 20, 2001 at 09:06:12AM -0500, Gibbs Tanton - tgibbs wrote:
> Failed 1/5 test scripts, 80.00% okay. 7/74 subtests failed, 90.54% okay.
> make: *** [test] Error 2
>
> Damien, is there any way we could get a similar fix for number.t? That
> would make us at 100% on Tru64.
I'm currently
On Thu, Sep 20, 2001 at 09:06:12AM -0500, Gibbs Tanton - tgibbs wrote:
> Damien, is there any way we could get a similar fix for number.t? That
> would make us at 100% on Tru64.
(Apologies if this shows up twice; something appears to be screwy with
my mail system.)
I'm currently getting segfaul
Ok, I applied Damien's integer.t fix and we now get:
Failed Test Stat Wstat Total Fail Failed List of Failed
---
t/op/number.t7 1792237 30.43% 1 7 9 11 13 15 17
4 subtests skipped.
Failed 1/5 test scri
27 matches
Mail list logo
