New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mixup in candidates through optimizer #5460
Comments
From @lizmatm: Buf.new((my int $i = 10) +& 0xFF) 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 multi sub infix:<+&>(Int:D \a, Int:D \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 @MARTIMMHi Elizabeth, Need to mention that there was a ticket #128624 created 'Buf Regards, |
The RT System itself - Status changed from 'new' to 'open' |
From @cokePlease reply to all on tickets, so that comments also end up back in On Mon, Jul 18, 2016 at 4:10 AM, mt1957 <mt1957@gmail.com> wrote:
-- |
From @zoffixznetPosting 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 dogbert@dogbert-VirtualBox ~ $ perl6 -v # the problem # run the same snippet with --optimize=0 # also works with --optimize=1 A discussion wrt this particular problem can be found here: https://irclog.perlgeek.de/perl6/2016-10-04#i_13335782 |
From @zoffixznetI 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 @dogbert17On Tue, 31 Jan 2017 09:05:52 -0800, cpan@zoffix.com wrote:
It turns out that he part reported 'on behalf of dogbert17', se above, describes a |
From @dogbert17On Sat, 15 Jul 2017 07:15:05 -0700, jan-olof.hendig@bredband.net wrote:
Also, the original problem has been 'temporarily' solved with rakudo/rakudo@242baf2 |
From @zoffixznetOn Sat, 15 Jul 2017 09:47:40 -0700, jan-olof.hendig@bredband.net wrote:
Thank you for the report. This is now fixed. Fix: rakudo/rakudo@29fdb75a30 |
@zoffixznet - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#128655 (status was 'resolved')
Searchable as RT128655$
The text was updated successfully, but these errors were encountered: