From @masak

<az5112> printf "%d\n", (9 % (-9)) produces -9 in rakudo -- is this a bug?
<masak> az5112​: was just going to eval that :)
<masak> az5112​: welcome ;)
<masak> nom​: say 9 % -9
<p6eval> nom ea0311​: OUTPUT«0␤»
<masak> nom​: say (9 % (-9))
<p6eval> nom ea0311​: OUTPUT«-9␤»
<masak> hm.
<masak> why do those two even differ?
<masak> so the result should still be 0, right?
<TimToady> masak​: sure, looks like a nom bug to me
* masak submits rakudobug
<TimToady> nom​: say 0 % (-9)
<p6eval> nom ea0311​: OUTPUT«-9␤»
<masak> b​: say 9 % -9; say 9 % (-9)
<p6eval> b 1b7dd1​: OUTPUT«0␤0␤»
<masak> yep. definitely a bug.
<masak> az5112++
<masak> az5112​: I'm always very happy when p6cc contestants catch bugs for us :)

Looking at it more closely, I see both a parsing bug and an arithmetic bug here.

* Parsing bug​: C<9 % -9> differs from C<9 % (-9)>. It shouldn't.
* Arithmetic bug​: C<9 % (-9)> yields -9 rather than the correct
answer, 0. -9 is even outside of the range of *possible* values for
C<$x % (-9)>.

From @moritz

The arithmetic bug has been fixed in 2011.12-44-g13f3e6d, tests are in
S03-operators/arith.t. I have no idea about the parsing bug though.

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

From @moritz

The parsing bug has also been fixed.

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