From mboxrd@z Thu Jan  1 00:00:00 1970
From: erik quanstrom <quanstro@labs.coraid.com>
Date: Fri, 23 Apr 2010 18:34:56 -0400
To: 9fans@9fans.net
Message-ID: <5a6d0c09e489554087dcb101dd96e727@coraid.com>
In-Reply-To: <y2y13426df11004231346q415d2c3cy7c760325968d92c4@mail.gmail.com>
References: <239c41a785c8c5638338c2f007f50733@vitanuova.com>
	<20100423200815.03B385B4A@mail.bitblocks.com>
	<y2y13426df11004231346q415d2c3cy7c760325968d92c4@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] BUG!!! in Plan9 compiler!
Topicbox-Message-UUID: 0ce92cb8-ead6-11e9-9d60-3106f5b1d025

> On Fri, Apr 23, 2010 at 1:08 PM, Bakul Shah <bakul+plan9@bitblocks.com> wrote:
>
> >
> > 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.

- erik