From @lizmat

[17​:01​:04] <lizmat> m​: my $a = 42; say $a =​:= $a; say $a.WHAT =​:= $a.WHAT; say $a == $a; say $a =​:= $a || $a.WHAT =​:= $a.WHAT # where does the 1 come from ???
[17​:01​:05] <camelia> rakudo-moar fe2be6​: OUTPUT«True␤True␤True␤1␤»
[17​:03​:18] <jnthn> m​: my $a = 42; say $a =​:= $a || $a.WHAT =​:= $a.WHAT
[17​:03​:18] <camelia> rakudo-moar fe2be6​: OUTPUT«1␤»
[17​:03​:29] <jnthn> m​: my $a = 42; say ($a =​:= $a) || ($a.WHAT =​:= $a.WHAT)
[17​:03​:29] <camelia> rakudo-moar fe2be6​: OUTPUT«1␤»
[17​:03​:35] <jnthn> m​: my $a = 42; say 0 || ($a.WHAT =​:= $a.WHAT)
[17​:03​:35] <camelia> rakudo-moar fe2be6​: OUTPUT«True␤»
[17​:03​:46] <jnthn> m​: my $a = 42; say ($a =​:= $a) || (say 'huh')
[17​:03​:46] <camelia> rakudo-moar fe2be6​: OUTPUT«1␤»
[17​:03​:57] <jnthn> m​: my $a = 42; say $a =​:= $a
[17​:03​:57] <camelia> rakudo-moar fe2be6​: OUTPUT«True␤»
[17​:04​:01] <jnthn> m​: my $a = 42; say ?($a =​:= $a)
[17​:04​:02] <camelia> rakudo-moar fe2be6​: OUTPUT«True␤»
[17​:04​:19] <jnthn> m​: my $a = 42; say do unless $a =​:= $a { 'x' }
[17​:04​:19] <camelia> rakudo-moar fe2be6​: OUTPUT«()␤»
[17​:04​:25] <jnthn> lizmat​: I...have no idea!
[17​:04​:45] <jnthn> Does it show up with --optimize=off?
[17​:04​:49] <lizmat> do you agree this is spooky?
[17​:04​:54] <jnthn> Yes :)
[17​:05​:26] <jnthn> m​: my $a = 42; say (($a =​:= $a) or ($a.WHAT =​:= $a.WHAT))
[17​:05​:26] <camelia> rakudo-moar fe2be6​: OUTPUT«1␤»
[17​:05​:42] <jnthn> m​: my $a = 42; say (($a =​:= $a) // ($a.WHAT =​:= $a.WHAT))
[17​:05​:42] <camelia> rakudo-moar fe2be6​: OUTPUT«True␤»
[17​:05​:45] <lizmat> indeed, this shows up from optimize=2
[17​:06​:12] <jnthn> m​: use nqp; my $a = 42; say nqp​::unless($a =​:= $a, $a.WHAT =​:= $a.WHAT)
[17​:06​:12] <camelia> rakudo-moar fe2be6​: OUTPUT«1␤»
[17​:06​:15] <lizmat> $ perl6 --optimize=1 -e 'my $a = 42; say $a =​:= $a || $a.WHAT =​:= $a.WHAT'
[17​:06​:15] <lizmat> True
[17​:06​:23] <lizmat> $ perl6 --optimize=2 -e 'my $a = 42; say $a =​:= $a || $a.WHAT =​:= $a.WHAT'
[17​:06​:23] <lizmat> 1
[17​:06​:32] <jnthn> Well, that isolates it a good bit, then :)
[17​:06​:44] <lizmat> rakudobug it ?
[17​:06​:48] <jnthn> yeah
[17​:06​:52] <lizmat> ok, will do
[17​:07​:00] <jnthn> I wonder if it's elimiating a nqp​::p6bool thinking it's not needed
[17​:08​:50] <lizmat> around line 1250 in Optimizer seems to be applicable
[17​:08​:59] <lizmat> way over my head, though...

From @lizmat

uguexe++ reporting, sortiz++ for following up

http://irclog.perlgeek.de/p6dev/2016-05-07#i_12446753

<lizmat> m​: my $a = "a"; say $a =​:= $a # yeah, True
<camelia> rakudo-moar ac36d2​: OUTPUT«True␤»
<lizmat> m​: my $a = "a"; say $a =​:= $a || 0 # WAT?
<camelia> rakudo-moar ac36d2​: OUTPUT«1␤»
<sortiz> Oops!
<lizmat> *that's* the underlying bug
<lizmat> m​: say "a" =​:= "a" || 0 # must be runtime
<camelia> rakudo-moar ac36d2​: OUTPUT«True␤»
<sortiz> That seems of another level to me.
<lizmat> looks like an optimizer bug​:
<lizmat> $ perl6 --optimize=0 -e 'my $a = "a"; say $a =​:= $a || 0'
<lizmat> True
<lizmat> $ perl6 --optimize=2 -e 'my $a = "a"; say $a =​:= $a || 0'
<lizmat> 1
<lizmat> level 2 and up

From @zoffixznet

Still present in This is Rakudo version 2016.06-154-g55c359e built on MoarVM version 2016.06-9-g8fc21d5

zoffix@​VirtualBox​:~$ perl6 --optimize=1 -e 'my $a = 42; say $a =​:= $a || $a.WHAT =​:= $a.WHAT'
True
zoffix@​VirtualBox​:~$ perl6 --optimize=2 -e 'my $a = 42; say $a =​:= $a || $a.WHAT =​:= $a.WHAT'
1

From @usev6

I think the p6bool is removed here​: https://github.com/rakudo/rakudo/blob/605f272881a76f0c5a9e352670a1e61eaa627ca6/src/Perl6/Optimizer.nqp#L1300

As far as I understand, the following code shows the problem at a lower level (no differentiation between optimize=(1|2) required -- it happens on all levels)​:

$ ./perl6-m --optimize=off -e 'use nqp; say nqp​::unless(nqp​::p6bool(nqp​::iseq_i(42,42)), False)'
True

$ ./perl6-m --optimize=0 -e 'use nqp; say nqp​::unless(nqp​::p6bool(nqp​::iseq_i(42,42)), False)'
1

I have no idea how it can be fixed, though. Maybe it's not even feasible to do what the comment above the relevant code block promises?

  # Some ops have first boolean arg, and we may be able to get rid of
  # a p6bool if there's already an integer result behind it.

@usev6 - Status changed from 'new' to 'open'

From @dogbert17

On Fri, 07 Oct 2016 14​:03​:39 -0700, bartolin@​gmx.de wrote​:

I think the p6bool is removed here​:
https://github.com/rakudo/rakudo/blob/605f272881a76f0c5a9e352670a1e61eaa627ca6/src/Perl6/Optimizer.nqp#L1300

As far as I understand, the following code shows the problem at a
lower level (no differentiation between optimize=(1|2) required -- it
happens on all levels)​:

$ ./perl6-m --optimize=off -e 'use nqp; say
nqp​::unless(nqp​::p6bool(nqp​::iseq_i(42,42)), False)'
True

$ ./perl6-m --optimize=0 -e 'use nqp; say
nqp​::unless(nqp​::p6bool(nqp​::iseq_i(42,42)), False)'
1

I have no idea how it can be fixed, though. Maybe it's not even
feasible to do what the comment above the relevant code block
promises?

# Some ops have first boolean arg, and we may be able to get rid of
# a p6bool if there's already an integer result behind it.

Looks as if this was fixed with rakudo/rakudo@f8b3469. Tests needed.

From @dogbert17

On Fri, 14 Jul 2017 13​:31​:42 -0700, jan-olof.hendig@​bredband.net wrote​:

On Fri, 07 Oct 2016 14​:03​:39 -0700, bartolin@​gmx.de wrote​:

I think the p6bool is removed here​:
https://github.com/rakudo/rakudo/blob/605f272881a76f0c5a9e352670a1e61eaa627ca6/src/Perl6/Optimizer.nqp#L1300

As far as I understand, the following code shows the problem at a
lower level (no differentiation between optimize=(1|2) required -- it
happens on all levels)​:

$ ./perl6-m --optimize=off -e 'use nqp; say
nqp​::unless(nqp​::p6bool(nqp​::iseq_i(42,42)), False)'
True

$ ./perl6-m --optimize=0 -e 'use nqp; say
nqp​::unless(nqp​::p6bool(nqp​::iseq_i(42,42)), False)'
1

I have no idea how it can be fixed, though. Maybe it's not even
feasible to do what the comment above the relevant code block
promises?

# Some ops have first boolean arg, and we may be able to get rid of
# a p6bool if there's already an integer result behind it.

Looks as if this was fixed with
rakudo/rakudo@f8b3469.
Tests needed.

Added in Raku/roast@39802b5b2b. Closing issue.

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