Date: Mon, 13 May 2002 10:12:38 +0100 From: Doug Rabson <dfr@nlsystems.com> To: John Baldwin <jhb@FreeBSD.org>, Alan Cox <alc@cs.rice.edu> Cc: Jeff Roberson <jroberson@chesapeake.net>, alpha@FreeBSD.org, obrien@FreeBSD.org, Andrew Gallatin <gallatin@cs.duke.edu> Subject: Re: gcc3 & alpha kernels Message-ID: <200205131012.38702.dfr@nlsystems.com> In-Reply-To: <XFMail.20020510235017.jhb@FreeBSD.org> References: <XFMail.20020510235017.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200205131012.38702.dfr>