> capture we wrote into:
>
>m: say "hi hi ho" ~~ /(\w+) \s+ $10=[$0] \s+ (\w+)/
>rakudo-moar 476741: OUTPUT: «｢hi hi ho｣ 0 => ｢hi｣ 10 => ｢hi｣ 11 =>
> ｢ho｣»
>
>
> If it's not, it need
> capture we wrote into:
>
>m: say "hi hi ho" ~~ /(\w+) \s+ $10=[$0] \s+ (\w+)/
>rakudo-moar 476741: OUTPUT: «｢hi hi ho｣ 0 => ｢hi｣ 10 => ｢hi｣ 11 =>
> ｢ho｣»
>
>
> If it's not, it need
tures continue their numbering
> from the capture we wrote into
This is documented in the design docs as intentional:
http://design.perl6.org/S05.html#Numbered_scalar_aliasing
(Except for the overflow bug, of course.)
i hi ho｣ 0 => ｢hi｣ 10 => ｢hi｣ 11 => ｢ho｣»
If it's not, it needs to be plugged up. And if it is, then it has this is the
bug with overflow:
m: say "hi" ~~ /
$10=(\w) (.)/
rakudo-moar 476741: OUTPUT: «｢hi｣ -6917529027641081856 => ｢h｣ 0 => ｢i｣»
I'm not sure if this is closable. The regression is no longer there, so I'll
remove the tag, but here's a problem:
Code:
say (4,5,6).tail(-2**63+4)
Result:
()
Code:
say (4,5,6,7).tail(-2**63+4)
Result:
Cannot unbox 64 bit wide bigint into native integer
in block at -e line 1
It feels like s
I’m inclined to WONTFIX, as other, much more common, indexing operation suffer
from the same issue:
$ 6 'my @a; say @a[999]'
Cannot unbox 64 bit wide bigint into native integer
$ 6 'my @a[999]'
Illegal dimension in shape: 999. All dimensions must b
I’m inclined to WONTFIX, as other, much more common, indexing operation suffer
from the same issue:
$ 6 'my @a; say @a[999]'
Cannot unbox 64 bit wide bigint into native integer
$ 6 'my @a[999]'
Illegal dimension in shape: 999. All dimensions must b
On Fri, 07 Apr 2017 19:16:17 -0700, alex.jakime...@gmail.com wrote:
> This no longer prints 256.
>
> Bisectable points to
> https://github.com/rakudo/rakudo/commit/5401a1aa8f12c360ccd3e4000dcdc65ad98c746a
>
> Is it actually resolved or not?
>
> I will mark it testneeded for now (if it's not reso
ric overflow
in block at /tmp/GYbmLKwQ4g line 1
Actually thrown at:
in block at /tmp/GYbmLKwQ4g line 1
Result (HEAD):
0
I am not sure what is the best solution here, but I guess having an exception
if the value is being zeroed is a good idea.
# New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev
# Please include the string: [perl #130290]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=130290 >
Code:
my @a = ; @a[*-18446744073709551616]:delete; say @a
Result (2
# New Ticket Created by Aleks-Daniel Jakimenko-Aleksejev
# Please include the string: [perl #130285]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=130285 >
Code:
say (4,5,6).tail(-999)
Result HEAD:
MoarVM pan
gt; 2**-1019
1.78005908680576e-307
> 2**-1020
Numeric overflow
in block at line 1
The result for 2**-1020 is bogus. The exact value of the operation
is representable in the Num type, as was used to represent the result
of 2**-1019.
-zefram
The problems regarding negative overflows seem to be fixed. All tests for this
ticket are passing. I'm closing this ticket as 'resolved'.
For the related discussion (different behavior of nqp::index with negative
$startpos between Moar and JVM) I opened a new ticket:
https://rt.perl.org/Ticket
big-e = 4553535345364535345634543534;
say (-2) ** $big-e
Result (MoarVM on Linux):
Numeric overflow
in block at ./test.p6 line 3
Actually thrown at:
in block at ./test.p6 line 3
Result (MoarVM on OS X):
1
Obviously, 1 is blatantly wrong.
Relevant test changes:
https://github.com/pe
# New Ticket Created by Alex Jakimenko
# Please include the string: [perl #127493]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=127493 >
Some tests in S32-num/power.t are assuming that big int exponents should result
in Inf
Brian S. Julin via RT skribis 2016-01-03 15:37 (-0800):
> S02-types/native.t would seem a ood place for testing scalar sized uints.
Thanks. Unfortunately, I couldn't easily figure out how to write TODO
tests. So here's something that someone could copy and paste:
# RT #127144, uint increment
That highlights the bug:
m: my uint8 $x = 255; print $x, " -> "; $x = $x + 1; say $x;
rakudo-moar 0f26ae: OUTPUT«255 -> 0»
m: my uint8 $x = 255; print $x, " -> "; $x++; say $x;
rakudo-moar 0f26ae: OUTPUT«255 -> 256»
Am 04.01.2016 um 11:48 schrieb Elizabeth Mattijsen:
On 04 Jan 2016, at 00:25
Just speculating, but I think this can be fixed by codegen; to be specific,
the inc_i op should be followed by a truncate in case of a sized variable.
2016-01-04 11:37 GMT+01:00 Elizabeth Mattijsen :
> > On 04 Jan 2016, at 00:25, Juerd Waalboer (via RT) <
> perl6-bugs-follo...@perl.org> wrote:
>
> On 04 Jan 2016, at 00:25, Juerd Waalboer (via RT)
> wrote:
>
> # New Ticket Created by Juerd Waalboer
> # Please include the string: [perl #127144]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/Ticket/Display.html?id=127144 >
>
>
> Bug:
>
> On 04 Jan 2016, at 00:25, Juerd Waalboer (via RT)
> wrote:
>
> # New Ticket Created by Juerd Waalboer
> # Please include the string: [perl #127144]
> # in the subject line of all future correspondence about this issue.
> # https://rt.perl.org/Ticket/Display.html?id=127144 >
>
>
> Bug:
>
# New Ticket Created by Juerd Waalboer
# Please include the string: [perl #127144]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=127144 >
Bug:
> my uint8 $x = 255; print $x, " -> "; $x = $x + 1; say $x;
255 -> 0
Wor
It looks like the overflow still happens. (Expected result is different
nowadays, since negative start positions are disallowed (see
https://github.com/rakudo/rakudo/commit/fa3ce116e3).
See also http://irclog.perlgeek.de/perl6/2015-11-21#i_11577908
$ perl6-m -e 'say index(&quo
On Tue Aug 11 01:15:38 2015, elizabeth wrote:
> Fixed with 14939e39d24541cc29fd12, tests added with e29df31, closable
Great, ticket closed.
Fixed with 14939e39d24541cc29fd12, tests added with e29df31, closable
> On 11 Aug 2015, at 02:47, Alex Jakimenko (via RT)
> wrote:
>
> # New Ticket Created by Alex Jakimenko
> # Please include the string: [perl #125784]
> # in the subject line of all future correspondence about this issue.
Fixed with 14939e39d24541cc29fd12, tests added with e29df31, closable
> On 11 Aug 2015, at 02:47, Alex Jakimenko (via RT)
> wrote:
>
> # New Ticket Created by Alex Jakimenko
> # Please include the string: [perl #125784]
> # in the subject line of all future correspondence about this issue.
# New Ticket Created by Alex Jakimenko
# Please include the string: [perl #125784]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=125784 >
Code:
say index 'xxy', 'y',
-99
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #117739]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org:443/rt3/Ticket/Display.html?id=117739 >
r: say :999('dd')
rakudo ef73eb: OUTPUT«Cannot convert stri
On Fri Apr 30 07:57:00 2010, bbkr wrote:
> This returns NAN now (in my case on 1024th operation)
>
>
> perl6 -e 'my $d = 2; my $p = 1; for 1..1024 { print "operation $_: ";
> say $p *= ($d-1)/($d); $d *= 2 }'
>
> operation 1017: 0.288788095086602
> operation 1018: 0.288788095086602
> operation 1
On Fri Apr 30 07:57:00 2010, bbkr wrote:
> This returns NAN now (in my case on 1024th operation)
>
>
> perl6 -e 'my $d = 2; my $p = 1; for 1..1024 { print "operation $_: ";
> say $p *= ($d-1)/($d); $d *= 2 }'
>
> operation 1017: 0.288788095086602
> operation 1018: 0.288788095086602
> operation 1
# New Ticket Created by Lithos
# Please include the string: [perl #77014]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=77014 >
Hi!
Integer literals >int32 seem to overflow on my machine without any
warning or
Here's a patch that gets PCT to avoid generating the constants
that IMCC can't handle, S03-operators/arith.t passes with this
patch. (I'm not in a place where I can do a full spectest_regression,
so I'm leaving the patch here for someone else to apply and test.)
Pm
Index: compilers/pct/src/PAST/C
On Thu, Sep 25, 2008 at 02:01:22PM -0700, chromatic wrote:
> On Thursday 25 September 2008 00:09:37 Moritz Lenz wrote:
> > As of today (and r31404) Rakudo's 'make spectest_regression' produces
> > compile time errors in three files, all of which are related to intege
On Thursday 25 September 2008 00:09:37 Moritz Lenz wrote:
> As of today (and r31404) Rakudo's 'make spectest_regression' produces
> compile time errors in three files, all of which are related to integer
> overflow.
>
> To reproduce:
> $ cd languages/p
duces
compile time errors in three files, all of which are related to integer
overflow.
To reproduce:
$ cd languages/perl6
$ make spectest_regression
$ ../../parrot perl6.pbc t/spec/S03-operators/arith.rakudo
add_1_const:Integer overflow '2147483648'
current instr.: 'parrot;PCT::HLL
It seems that the error condition refers to the case where too many
arguments are passed (#args > #params).It's not really "overflow" in that
sense, IMHO, just "too many arguments passed".
I think an exception is already thrown when that happens, not sure.
kjs
On
>> What would be the best way to handle this? We certainly don't need to do
>> anything on systems where INT_MAX == -INT_MIN, but a simple compiler
>> directive should help to detect that case.
>>
>> In the event that abs(INT_MIN) > abs(INT_MAX), should we silently
>> saturate the result to INT_MAX
On Thu Feb 21 12:15:06 2008, Whiteknight wrote:
> What would be the best way to handle this? We certainly don't need to do
> anything on systems where INT_MAX == -INT_MIN, but a simple compiler
> directive should help to detect that case.
>
> In the event that abs(INT_MIN) > abs(INT_MAX), should
On Monday 08 September 2008 12:57:00 Christoph Otto via RT wrote:
> On Tue Sep 11 03:32:51 2007, pcoch wrote:
> > Having a look through PDD03 I noticed the TODO item left by Chip:
> >
> > =head3 Overflow
> >
> > If too many values are provided to fit in
On Tue Sep 11 03:32:51 2007, pcoch wrote:
> Having a look through PDD03 I noticed the TODO item left by Chip:
>
> =head3 Overflow
>
> If too many values are provided to fit into the given target
> registers, Parrot
> will throw an exception. Note that if the final tar
amber sources are no longer stored in the parrot repository.
ticket rejected.
amber sources are no longer stored in the parrot repository.
ticket rejected.
tem:
METHOD PMC* integer() { /* XXX OVERFLOW */
which I'm guessing means that there is an overflow problem lurking in this
method. This needs to be corrected.
tem:
/* XXX overflow for -maxint */
There is therefore an overflow issue when trying to handle abs(-maxint).
This needs to be corrected.
for -maxint */
which I think means that before setting the integer value we need to check
here for overflow of -maxint (or at least numbers which go over the maximum
integer value allowed on the current platform, or something like that).
ent() methods:
/* XXX overflow */
As far as I can tell, this means to check for overflow before either
incrementing or decrementing.
int overflow */
I *believe* this means to check for possible big integer overflow issues at
this point in the code; especially before calling string_to_int().
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #46621]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=46621 >
In src/pmc/integer.pmc:overflow() there is the todo item:
/* TODO preserve type system
# New Ticket Created by Paul Cochrane
# Please include the string: [perl #45357]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=45357 >
Having a look through PDD03 I noticed the TODO item left by Chip:
=head3 Overf
Am Dienstag, 17. April 2007 23:48 schrieb Steve Peters:
> + strncpy(format, fmt, sizeof(format - 1));
Me thinks, that it's better to check the len of the format as it grows,
considering the amount what would be strcat'ed. If an index really would
overflow format, a proper
On Wed, Apr 18, 2007 at 11:18:20AM +0200, Mehmet Yavuz Selim Soyturk wrote:
> >+format[sizeof(format - 1)] = '\0';
>
>
> Shouldn't that be 'format[sizeof(format) - 1]' ?
>
Yes, thanks! Good catch!
Steve
+format[sizeof(format - 1)] = '\0';
Shouldn't that be 'format[sizeof(format) - 1]' ?
--
Mehmet
On Tuesday 17 April 2007 14:48, Steve Peters wrote:
> I don't know how easily this is reached, but since the "fmt" variable
> is only NULL checked, it seems like this would be possible to reached.
Hm, this patch breaks some tests for me:
t/compilers/imcc/imcpasm/optc.t1 256431 8
t
# New Ticket Created by Steve Peters
# Please include the string: [perl #42594]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=42594 >
I don't know how easily this is reached, but since the "fmt" variable
is only NULL check
On Wednesday 14 March 2007 23:00, via RT wrote:
> Index: include/parrot/sub.h
> ===
> --- include/parrot/sub.h(Revision 17473)
> +++ include/parrot/sub.h(Arbeitskopie)
> @@ -87,7 +87,6 @@
> SUB_COMP_FLAG_BIT_28 =
On Thu Mar 15 05:30:31 2007, nahoo wrote:
> On Mi. 14. Mär. 2007, 23:00:18, nahoo wrote:
> > Index: include/parrot/sub.h
> > ===
> > --- include/parrot/sub.h(Revision 17473)
> > +++ include/parrot/sub.h(Arbeitskopie)
>
# New Ticket Created by
# Please include the string: [perl #41837]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=41837 >
Index: include/parrot/sub.h
===
---
set I0, 0x8000
> >>div I1, I0, -1
> >>print I1
> >>print "\n"
> >>end
> > But out of curiosity, why would integer division be a floating point
> >exception?
>
> Lack of interrupt slots on x86?
>
> And why doesn'
ception?
I guess the Right Exception to throw would be an integer overflow exception
if we did that.
Just ignore it?
It's kinda worth asking "what is an I register" here. They're native size
already, so we could just say "they have native overflow/wrap-around
behaviour
0 is as valid but OTOH far away from the
correct result ;)
But out of curiosity, why would integer division be a floating point
exception?
Lack of interrupt slots on x86?
And why doesn't it set the overflow bit?
Oh, and on my iBook g3, I get -1.
Wow.
leo
Why not case it to switch it to 0x7fff? In any case, if the code's
added in to check for it an to throw an exception, then wouldn't it be
more friendly to return as close to what's expected, and just call it
"magical rounding"? But out of curiosity, why would integer division
be a floatin
Strange, but it exists for just on case (well not strange, there are
just more negative numbers ...):
$ cat div.pasm
set I0, 0x8000
div I1, I0, -1
print I1
print "\n"
end
Running it on PPC gives:
$ ./parrot div.pasm
0
And on x86:
$ ./parrot div.pasm
Floating point exception
What shall w
On Nov 30, 2005, at 22:16, Chip Salzenberg wrote:
Say, I just noticed this:
On Wed, Nov 30, 2005 at 12:18:40PM +0100, Leopold Toetsch wrote:
.sub foo
push_eh handler
get_params '(0)', $P0# no .params yet - sorry
I remember at one point that get_params had to be the fi
On Thu, Dec 01, 2005 at 01:45:49AM +0100, Leopold Toetsch wrote:
> While strict argument checking is and was always in the pdd03, it was
> not enforced and is only checkable since today. Therefore I'd like to
> keep current settings until after the release.
Works for me.
--
Chip Salzenberg <[EM
On Nov 30, 2005, at 22:08, Chip Salzenberg wrote:
On Wed, Nov 30, 2005 at 02:39:58PM -0600, Patrick R. Michaud wrote:
At any rate, I found and fixed the two PGE subs that weren't declaring
their (unused) parameters. All p6rules tests now appear to pass in
r10278 with .PARROT_ERRORS_PARAM_COUN
Say, I just noticed this:
On Wed, Nov 30, 2005 at 12:18:40PM +0100, Leopold Toetsch wrote:
>.sub foo
> push_eh handler
> get_params '(0)', $P0# no .params yet - sorry
I remember at one point that get_params had to be the first opcode in
the sub. I didn't like that, but I
On Wed, Nov 30, 2005 at 02:39:58PM -0600, Patrick R. Michaud wrote:
> At any rate, I found and fixed the two PGE subs that weren't declaring
> their (unused) parameters. All p6rules tests now appear to pass in
> r10278 with .PARROT_ERRORS_PARAM_COUNT_FLAG enabled.
Excellent.
Leo, would you be
On Wed, Nov 30, 2005 at 03:27:52PM -0500, Will Coleda wrote:
> On Nov 30, 2005, at 2:50 PM, Patrick R. Michaud wrote:
> >Thus, we really ought to have a way to indicate that a rule (parrot
> >sub) can still be safely run even if called with more parameters
> >than it expects.
>
> Isn't this what :
On Wed, Nov 30, 2005 at 03:27:52PM -0500, Will Coleda wrote:
> On Nov 30, 2005, at 2:50 PM, Patrick R. Michaud wrote:
> >Short answer: something like a ":last" flag would be excellent.
> >
> >Longer answer: In PGE, each rule is a parrot sub, and some rules
> >can be parameterized by various param
On Nov 30, 2005, at 2:50 PM, Patrick R. Michaud wrote:
On Wed, Nov 30, 2005 at 11:00:36AM -0800, Chip Salzenberg wrote:
On Wed, Nov 30, 2005 at 12:18:40PM +0100, Leopold Toetsch wrote:
Parrot didn't throw exceptions on param or result count mismatch
until now, and still doesn't. [1]
[1] all P
On Wed, Nov 30, 2005 at 11:00:36AM -0800, Chip Salzenberg wrote:
> On Wed, Nov 30, 2005 at 12:18:40PM +0100, Leopold Toetsch wrote:
> > Parrot didn't throw exceptions on param or result count mismatch
> > until now, and still doesn't. [1]
> > [1] all PGE and PGE-based stuff is failing, when both ar
On Wed, Nov 30, 2005 at 12:18:40PM +0100, Leopold Toetsch wrote:
> Parrot didn't throw exceptions on param or result count mismatch
> until now, and still doesn't. [1]
> [1] all PGE and PGE-based stuff is failing, when both are turned on
Exceptions should still be the default, even if PGE needs so
Parrot didn't throw exceptions on param or result count mismatch until
now, and still doesn't. [1]
But, I have invented 2 more error flag bits [2], which can enable
stricter argument checking and the exception is catchable in the
subroutine itself now:
.include "errors.pasm"
errorson .P
On 22/08/05, Luke Palmer <[EMAIL PROTECTED]> wrote:
> Output?
>
> sub foo (+$a, *%overflow) {
> say "%overflow{}";
> }
>
> foo(:a(1), :b(2)); # b2
> foo(:a(1), :overflow{ b => 2 }); # b
Hi,
Luke Palmer wrote:
> sub foo (+$a, *%overflow) {
> say "%overflow{}";
> }
>
> foo(:a(1), :b(2)); # b 2
> foo(:a(1), :overflow{ b => 2 }); # b2
I'd think so, too.
> foo(:a(1), :ov
Output?
sub foo (+$a, *%overflow) {
say "%overflow{}";
}
foo(:a(1), :b(2)); # b2
foo(:a(1), :overflow{ b => 2 }); # b2
foo(:a(1), :overflow{ b => 2 }, :c(3)); # ???
Luke
I also don't expect
$x = '';
$y = " $x ";
to assign '' to $y either, but that's the equlvalent of what you say
form() will do.
I see your point.
I was more worried about arrays of items some of which are empty strings
and having items disappear out my repost because form() throws them
aw
Damian Conway wrote:
But that means I have to pre-process data lists that just happen to
contain empty strings so that they won't disappear on me.
Huh? An empty string already *has* disappeared on you. ;-)
> This seems to violate least surprise.
I'd be much more surprised if an empty string *
But that means I have to pre-process data lists that just happen to
contain empty strings so that they won't disappear on me.
Huh? An empty string already *has* disappeared on you. ;-)
> This seems to violate least surprise.
I'd be much more surprised if an empty string *didn't* disappear.
After
Damian Conway wrote:
Mark A. Biggar wrote:
What if I want to interpolate an empty string and let the fill
characters work?
Then you interpolate a single fill character instead of the empty string.
But that means I have to pre-process data lists that just happen to
contain empty strings so that
Mark A. Biggar wrote:
What if I want to interpolate an empty string and let the fill
characters work?
Then you interpolate a single fill character instead of the empty string.
Damian
Damian Conway wrote:
Mark A. Biggar wrote:
Expect wouldn't that produce a extra blank line if $text is short?
Nope. Formats only generate text lines if at least one of their fields
interpolates at least one character.
Damian
What if I want to interpolate an empty string and let the fill
char
Mark A. Biggar wrote:
Expect wouldn't that produce a extra blank line if $text is short?
Nope. Formats only generate text lines if at least one of their fields
interpolates at least one character.
Damian
Luke Palmer wrote:
Arn't there cases where the overflow field want to be bigger then the
first field? Something the ends up looking like:
LABEL: texttexttextexttexttext
texttextexttextetexttexttextte
xttexttexttexttexttexttextttex
where LABEL is in one field and text... is in an oveflow
Luke Palmer wrote:
Mark A. Biggar writes:
Larry Wall wrote:
On Sat, Feb 28, 2004 at 11:59:15AM -0800, Gregor N. Purdy wrote:
: Smylers --
:
: So, what I'm looking for is more explicit phrasing around "immediately
: above". In the example, the column range for the overflow fie
Mark A. Biggar writes:
> Larry Wall wrote:
>
> >On Sat, Feb 28, 2004 at 11:59:15AM -0800, Gregor N. Purdy wrote:
> >: Smylers --
> >:
> >: So, what I'm looking for is more explicit phrasing around "immediately
> >: above". In the example, the
Larry Wall wrote:
On Sat, Feb 28, 2004 at 11:59:15AM -0800, Gregor N. Purdy wrote:
: Smylers --
:
: So, what I'm looking for is more explicit phrasing around "immediately
: above". In the example, the column range for the overflow field is
: exactly the same as that of the $meth
Gregor N. Purdy wrote:
So, what I'm looking for is more explicit phrasing around "immediately
above". In the example, the column range for the overflow field is
exactly the same as that of the $method field in the prior "picture".
But, what does it do if it doesn't m
On Sat, Feb 28, 2004 at 11:59:15AM -0800, Gregor N. Purdy wrote:
: Smylers --
:
: So, what I'm looking for is more explicit phrasing around "immediately
: above". In the example, the column range for the overflow field is
: exactly the same as that of the $method field in the
Smylers --
So, what I'm looking for is more explicit phrasing around "immediately
above". In the example, the column range for the overflow field is
exactly the same as that of the $method field in the prior "picture".
But, what does it do if it doesn't match *exa
Gregor N. Purdy writes:
> In "And now at length they overflow their banks." its not clear
> how an overflow field gets tied to its initial non-overflow field.
> In the recipe example given, how does it know to go with the
> $method field instead of the $prep_time field?
T
In "And now at length they overflow their banks." its not clear
how an overflow field gets tied to its initial non-overflow field.
In the recipe example given, how does it know to go with the
$method field instead of the $prep_time field? Is it basing off
of matching the horizontal ext
output:
>
> -2147483648
>
> but in JIT mode (on an x86) it produces:
>
> -0
>
> This smacks of some kind of overflow problem, but I haven't the faintest
> idea of where in jit.c to start looking.
Using 32bit representations, you just set the int value to 0x
of some kind of overflow problem, but I haven't the faintest
idea of where in jit.c to start looking.
Simon
[1] Incidentally, this is test 29 in t/op/number.t
93 matches
Mail list logo
