From mboxrd@z Thu Jan 1 00:00:00 1970 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-reply-to: Your message of "Fri, 23 Apr 2010 18:34:56 EDT." <5a6d0c09e489554087dcb101dd96e727@coraid.com> References: <239c41a785c8c5638338c2f007f50733@vitanuova.com> <20100423200815.03B385B4A@mail.bitblocks.com> <5a6d0c09e489554087dcb101dd96e727@coraid.com> From: Bakul Shah Date: Sat, 24 Apr 2010 11:59:13 -0700 Message-Id: <20100424185913.9A9CC5B42@mail.bitblocks.com> Subject: Re: [9fans] BUG!!! in Plan9 compiler! Topicbox-Message-UUID: 0cf0f3a8-ead6-11e9-9d60-3106f5b1d025 On Fri, 23 Apr 2010 18:34:56 EDT erik quanstrom wrote: > > On Fri, Apr 23, 2010 at 1:08 PM, Bakul Shah wro > te: > > > > > > > > If so, I consider it a bug; particularly as there is no > > > overflow involved anywhere. > > > > > > > > > > r1 2147482110 r2 -1537 > > on arm the difference is interesting. the first > / is translated: > main+0x20 0x00001040 MOVW (R4>>1),R4 > and the second: > main+0x34 0x00001054 ADD.MI $#0x1,R2,R2 > main+0x38 0x00001058 MOVW (R2->1),R2 > > (5c -S has it SRL and SRA, respectively.) > if we are unsigned preserving, wouldn't this make sense, since > (x + y + z) is an unsigned expression but (x + y) is not. It is clear that there is no one *right* answer for how mixed signed/unsigned number operations should be treated but c89 rules do seem a bit more sensible to me as they avoid surprises like (x + y + 0u)/z being different from (x + y)/z, where x,y,z are signed ints. Is this behaviour really useful for anything? Is there anything in plan9 code that relies on this behaviour in a critical way? I suspect this rule can be changed without impacting plan 9 code much (which as a rule is of much higher quality than most open source code) and we already know programs ported to p9p work fine. Anyway, I think I've said all I want to on this topic! Probably more than.