From owner-freebsd-alpha  Mon May 13  2:14:33 2002
Delivered-To: freebsd-alpha@freebsd.org
Received: from anchor-post-30.mail.demon.net (anchor-post-30.mail.demon.net [194.217.242.88])
	by hub.freebsd.org (Postfix) with ESMTP
	id 00B2437B40A; Mon, 13 May 2002 02:14:04 -0700 (PDT)
Received: from mailgate.nlsystems.com ([62.49.251.130] helo=herring.nlsystems.com)
	by anchor-post-30.mail.demon.net with esmtp (Exim 3.35 #1)
	id 177Bu2-0004R0-0U; Mon, 13 May 2002 10:13:58 +0100
Received: from herring.nlsystems.com (localhost [127.0.0.1])
	by herring.nlsystems.com (8.12.3/8.11.2) with ESMTP id g4D9CevN050767;
	Mon, 13 May 2002 10:12:40 +0100 (BST)
	(envelope-from dfr@herring.nlsystems.com)
Received: (from dfr@localhost)
	by herring.nlsystems.com (8.12.3/8.12.3/Submit) id g4D9CcQg050766;
	Mon, 13 May 2002 10:12:38 +0100 (BST)
Content-Type: text/plain;
  charset="iso-8859-1"
From: Doug Rabson <dfr@nlsystems.com>
To: John Baldwin <jhb@FreeBSD.org>, Alan Cox <alc@cs.rice.edu>
Subject: Re: gcc3 & alpha kernels
Date: Mon, 13 May 2002 10:12:38 +0100
User-Agent: KMail/1.4.1
Cc: Jeff Roberson <jroberson@chesapeake.net>, alpha@FreeBSD.org,
	obrien@FreeBSD.org, Andrew Gallatin <gallatin@cs.duke.edu>
References: <XFMail.20020510235017.jhb@FreeBSD.org>
In-Reply-To: <XFMail.20020510235017.jhb@FreeBSD.org>
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Message-Id: <200205131012.38702.dfr@nlsystems.com>
Sender: owner-freebsd-alpha@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-alpha.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20freebsd-alpha>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20freebsd-alpha>
X-Loop: FreeBSD.org

On Saturday 11 May 2002 4:50 am, John Baldwin wrote:
> On 11-May-2002 Alan Cox wrote:
> > On Fri, May 10, 2002 at 08:48:37PM -0400, John Baldwin wrote:
> >> ... I suggest that all the atomic
> >> ops buried in the vm code be checked very carefully for these types =
of
> >> short/int mismatches as well as any int/long mismatches and the like=
=2E
> >
> > In the MI parts of the vm, outside of _vm_object_allocate(),
> > there is only one other use of atomic ops and that simply
> > adds 1 to an u_int.  The rest were removed when Giant was
> > introduced.
>
> Hmm.  Ok, after talking with jeff@ it is getting weirder.  I was wrong
> at first as we are hanging on the second atomic_cmpset, not hte first
> (printf's help).  It seems that gcc has a bug (*sigh*) in that instead =
of
> usign 'zapnot' to zero extned the unsigned int it passes in, it is now
> using addl s0,zero,s0, but addl does sign extension on its result, so n=
ow
> we get a sign extended version to compare against.  Thus, one way of fi=
xing
> this is to revert Jeff's earlier fix.  However, it is arguably wrong fo=
r
> gcc to be sign-extending the unsigned int it is passing in.

I've seen similar behaviour with gcc3 on ia64.

--=20
Doug Rabson=09=09=09=09Mail:  dfr@nlsystems.com
=09=09=09=09=09Phone: +44 20 8348 6160


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-alpha" in the body of the message