From owner-freebsd-current  Sun Dec 10  5: 4:55 2000
From owner-freebsd-current@FreeBSD.ORG  Sun Dec 10 05:04:53 2000
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16])
	by hub.freebsd.org (Postfix) with ESMTP
	id A3DED37B400; Sun, 10 Dec 2000 05:04:50 -0800 (PST)
Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102])
	by mailman.zeta.org.au (8.8.7/8.8.7) with ESMTP id AAA27011;
	Mon, 11 Dec 2000 00:01:36 +1100
Date: Mon, 11 Dec 2000 00:02:57 +1100 (EST)
From: Bruce Evans <bde@zeta.org.au>
X-Sender: bde@besplex.bde.org
To: atrens@nortel.ca
Cc: John Baldwin <jhb@FreeBSD.ORG>, current@FreeBSD.ORG
Subject: Re: possibly related data point - (was) Re: Current Broken!
In-Reply-To: <Pine.BSF.4.30.0012072234320.29280-100000@hcarp00g.ca.nortel.com>
Message-ID: <Pine.BSF.4.21.0012102336300.714-100000@besplex.bde.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

On Thu, 7 Dec 2000 atrens@nortel.ca wrote:

> I'm not a constraints expert either, but I noticed that when I try to
> build a kernel WITHOUT any optimization, I get a failure in
> 
> /usr/src/sys/i386/atomic.h .
> 
> # make atomic.o
> cc -c -O0 -pipe -Wall -Wredundant-decls -Wnested-externs
> ...
> /usr/src/sys/i386/i386/atomic.c
> In file included from /usr/src/sys/i386/i386/atomic.c:48:
> machine/atomic.h: In function `atomic_set_char':
> machine/atomic.h:178: inconsistent operand constraints in an `asm'

> with any optimization, eg -O, there is _NO_ error. Makes me think the optimizer
> is optimizing out the offending contraints.  Ouch. Probably not what was intended.
> 
> Maybe this is what's biting you ?

This is sort of the opposite of the bug in <machine/mutex.h>.  It is
believed to be caused by using the operand-number constraints (e.g.,
"(0)") to declare input-output operands in <machine/atomic.h>.
Input-output operands and/or these constraints apparently never worked
right until a recent versions of gcc introduced the "+" contraint to
declare input-output operations properly.  <machine/atomic.h> uses the
new constraint.  The problem seems to be that "+" contraints don't
work right either.

The following kludge fixes compilation of cam_periph.c:

diff -c2 mutex.h~ mutex.h
*** mutex.h~	Sun Dec 10 19:28:53 2000
--- mutex.h	Sun Dec 10 23:50:21 2000
***************
*** 171,174 ****
--- 176,180 ----
  									\
  	__asm __volatile (						\
+ "	movl	$" _V(MTX_UNOWNED) ",%%eax;"				\
  "	" MPLOCKED ""							\
  "	cmpxchgl %4,%0;"			/* try easy rel */	\
***************
*** 181,185 ****
  "# exitlock_norecurse"							\
  	: "+m" (mtxp->mtx_lock), 		/* 0 */			\
! 	  "+a" (_tid)				/* 1 */			\
  	: "gi" (type),				/* 2 (input) */		\
  	  "g" (mtxp),				/* 3 */			\
--- 187,191 ----
  "# exitlock_norecurse"							\
  	: "+m" (mtxp->mtx_lock), 		/* 0 */			\
! 	  "=&a" (_tid)				/* 1 */			\
  	: "gi" (type),				/* 2 (input) */		\
  	  "g" (mtxp),				/* 3 */			\

This bug seems to have been encountered before -- I copied this inferior
code from the function before the one that doesn't compile.  Several other
functions in <machine/mutex.h> also use it.

Bruce



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