From @lizmat

m​: Buf.new((my int $i = 10) +& 0xFF)
Type check failed in initializing element #​0 to Buf; expected uint8 but got Int (10)
in any at gen/moar/m-Metamodel.nqp line 1736␤ in block <unit> at <tmp> line 1

Actually thrown at​:␤ in any at gen/moar/m-Metamodel.nqp line 3055␤ in an…

On further inspection, it appears that the value found in the argument list is a BOOTInt, rather than an Int, and that fails the nqp​::istype($a,Int) test. It *feels* like it calling the int/int candidate, when it thinks it's calling the Int​:D/Int​:D candidate. Since the int/int candidate returns an int, but the optimizer probably thinks it is getting an Int, the native is not marshalled into an Int when it should.

This bug probably existed for a long time already, but was uncovered by de5d9e70cbfe678d2371d284 . Before, going through all of the iterator stuff, would marshall the int into an Int

It appears that all bitwise operators that return an int/Int have the same problem with the calling them with a native parameter. The problem goes away if optimizing is somehow inhibited, but that, I feel, is just masking the problem. Ways of stopping optimization are​:

- calling perl6 with —optimize=0 or —optimize=1
- adding an nqp​::null to the native int candidate

multi sub infix​:<+&>(Int​:D \a, Int​:D \b) {
  nqp​::bitand_I(nqp​::decont(a), nqp​::decont(b), Int)
}
multi sub infix​:<+&>(int $a, int $b) {
nqp​::null; # stops optimization
  nqp​::bitand_i($a, $b)
}

Note that the problem gets fixed by adding an optimizer stopper to the candidate that is *not* being called, as 0xFF is an Int, and thus int $i +& 0xFF is calling the Int​:D/Int​:D candidate!!

Since this idiom is quite normal, a quick fix seems in order.

From @MARTIMM

Hi Elizabeth,

Need to mention that there was a ticket #​128624 created 'Buf
initialization error'.

Regards,
Marcel Timmerman

The RT System itself - Status changed from 'new' to 'open'

From @coke

Please reply to all on tickets, so that comments also end up back in
RT as well. (I linked the tickets based on your comment here.)

On Mon, Jul 18, 2016 at 4​:10 AM, mt1957 <mt1957@​gmail.com> wrote​:

Hi Elizabeth,

Need to mention that there was a ticket #​128624 created 'Buf initialization
error'.

Regards,
Marcel Timmerman

--
Will "Coke" Coleda

From @zoffixznet

Posting on behalf of dogbert17​:

I believe that I have encountered the same bug under different circumstances. With the help of hackedNODE and others on #perl6
it seems as if the problem described below also suffers from the wrong multi candidate being called. In fact, it seems to happen
with any sub with int/Int multis.

dogbert@​dogbert-VirtualBox ~ $ perl6 -v
This is Rakudo version 2016.09-122-gc6c0e69 built on MoarVM version 2016.09-13-g34c375a
implementing Perl 6.c.

# the problem
dogbert@​dogbert-VirtualBox ~ $ perl6 -e 'my int $i = 2482111348; say $i; $i = $i div 2; say $i'
2482111348
-906427974

# run the same snippet with --optimize=0
dogbert@​dogbert-VirtualBox ~ $ perl6 --optimize=0 -e 'my int $i = 2482111348; say $i; $i = $i div 2; say $i'
2482111348
1241055674

# also works with --optimize=1
dogbert@​dogbert-VirtualBox ~ $ perl6 --optimize=1 -e 'my int $i = 2482111348; say $i; $i = $i div 2; say $i'
2482111348
1241055674

A discussion wrt this particular problem can be found here​: https://irclog.perlgeek.de/perl6/2016-10-04#i_13335782

From @zoffixznet

I dug at this bug a few months back, but lost my notes on my findings.

As I recall it, the 128655 happens in BOOTSTRAP.nqp in find_best_dispatchee() the non-native candidate ends up being first in the list and that's why it's used instead of native candidates.

I then went and wrote down the new rules for dispatch that would avoid that​: https://rt-archive.perl.org/perl6/Ticket/Display.html?id=129844

Then jnthn++ explained (https://irclog.perlgeek.de/perl6-dev/2016-10-25#i_13462673 ) that I misunderstood the auto[un]boxing behaviour of natives, so the new rules are out of the window. But that's where my journey ended and never re-examined this ticket with my new understanding of boxing.

From @dogbert17

On Tue, 31 Jan 2017 09​:05​:52 -0800, cpan@​zoffix.com wrote​:

I dug at this bug a few months back, but lost my notes on my findings.

As I recall it, the 128655 happens in BOOTSTRAP.nqp in
find_best_dispatchee() the non-native candidate ends up being first in
the list and that's why it's used instead of native candidates.

I then went and wrote down the new rules for dispatch that would avoid
that​: https://rt-archive.perl.org/perl6/Ticket/Display.html?id=129844

Then jnthn++ explained (https://irclog.perlgeek.de/perl6-dev/2016-10-
25#i_13462673 ) that I misunderstood the auto[un]boxing behaviour of
natives, so the new rules are out of the window. But that's where my
journey ended and never re-examined this ticket with my new
understanding of boxing.

It turns out that he part reported 'on behalf of dogbert17', se above, describes a
different problem which was fixed with rakudo/rakudo@c98b3a5

From @dogbert17

On Sat, 15 Jul 2017 07​:15​:05 -0700, jan-olof.hendig@​bredband.net wrote​:

On Tue, 31 Jan 2017 09​:05​:52 -0800, cpan@​zoffix.com wrote​:

I dug at this bug a few months back, but lost my notes on my
findings.

As I recall it, the 128655 happens in BOOTSTRAP.nqp in
find_best_dispatchee() the non-native candidate ends up being first
in
the list and that's why it's used instead of native candidates.

I then went and wrote down the new rules for dispatch that would
avoid
that​: https://rt-archive.perl.org/perl6/Ticket/Display.html?id=129844

Then jnthn++ explained (https://irclog.perlgeek.de/perl6-dev/2016-10-
25#i_13462673 ) that I misunderstood the auto[un]boxing behaviour of
natives, so the new rules are out of the window. But that's where my
journey ended and never re-examined this ticket with my new
understanding of boxing.

It turns out that he part reported 'on behalf of dogbert17', se above,
describes a
different problem which was fixed with
rakudo/rakudo@c98b3a5

Also, the original problem has been 'temporarily' solved with rakudo/rakudo@242baf2

From @zoffixznet

On Sat, 15 Jul 2017 09​:47​:40 -0700, jan-olof.hendig@​bredband.net wrote​:

On Sat, 15 Jul 2017 07​:15​:05 -0700, jan-olof.hendig@​bredband.net
wrote​:

On Tue, 31 Jan 2017 09​:05​:52 -0800, cpan@​zoffix.com wrote​:

I dug at this bug a few months back, but lost my notes on my
findings.

As I recall it, the 128655 happens in BOOTSTRAP.nqp in
find_best_dispatchee() the non-native candidate ends up being first
in
the list and that's why it's used instead of native candidates.

I then went and wrote down the new rules for dispatch that would
avoid
that​: https://rt-archive.perl.org/perl6/Ticket/Display.html?id=129844

Then jnthn++ explained (https://irclog.perlgeek.de/perl6-dev/2016-
10-
25#i_13462673 ) that I misunderstood the auto[un]boxing behaviour
of
natives, so the new rules are out of the window. But that's where
my
journey ended and never re-examined this ticket with my new
understanding of boxing.

It turns out that he part reported 'on behalf of dogbert17', se
above,
describes a
different problem which was fixed with
rakudo/rakudo@c98b3a5

Also, the original problem has been 'temporarily' solved with
rakudo/rakudo@242baf2

Thank you for the report. This is now fixed.

Fix​: rakudo/rakudo@29fdb75a30
  rakudo/rakudo@3d7359755698458
Test​: Raku/roast@32ac651062f3ba06f

@zoffixznet - Status changed from 'open' to 'resolved'