From owner-svn-src-head@FreeBSD.ORG Sat Aug 21 13:59:41 2010 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7E57D1065693; Sat, 21 Aug 2010 13:59:41 +0000 (UTC) (envelope-from dimitry@andric.com) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 4057D8FC12; Sat, 21 Aug 2010 13:59:41 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:5bf:3b80:dc99:ff32] (unknown [IPv6:2001:7b8:3a7:0:5bf:3b80:dc99:ff32]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 243425C59; Sat, 21 Aug 2010 15:59:40 +0200 (CEST) Message-ID: <4C6FDBCF.6070101@andric.com> Date: Sat, 21 Aug 2010 15:59:43 +0200 From: Dimitry Andric User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.2.9pre) Gecko/20100814 Lanikai/3.1.3pre MIME-Version: 1.0 To: Bruce Evans References: <201008191259.o7JCxv3i004613@svn.freebsd.org> <20100820075236.L18914@delplex.bde.org> <4C6DC0F8.9040001@andric.com> <20100821054033.M19850@delplex.bde.org> In-Reply-To: <20100821054033.M19850@delplex.bde.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Rui Paulo Subject: Re: svn commit: r211505 - head/contrib/gcc X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Aug 2010 13:59:41 -0000 On 2010-08-20 22:36, Bruce Evans wrote: > On Fri, 20 Aug 2010, Dimitry Andric wrote: [...] >> But will the casts not potentially hide problems, if you pass the wrong >> types to those macros? Maybe it is better if the compiler complains >> that some argument is of an incompatible type, than just forcing it to >> cast? > This is unclear. All integer types are compatible to some extent. > Upcasting them always works and downcasting them works iff the value > is not changed. I meant this in the context of this llvm PR, about matching inline asm input constraints with output constraints of an incompatible type: http://llvm.org/bugs/show_bug.cgi?id=3373 Clang is currently somewhat pickier about the arguments to inline asm, which we also noticed in OpenSSL code, where a rotate-left macro is defined (for i386 and amd64) as: # define ROTATE(a,n) ({ register unsigned int ret; \ asm ( \ "roll %1,%0" \ : "=r"(ret) \ : "I"(n), "0"(a) \ : "cc"); \ ret; \ }) On amd64, it was being called with the 'a' argument being of unsigned long type. Clang complained: crypto/openssl/crypto/md4/md4_dgst.c:117:2: error: unsupported inline asm: input with type 'unsigned long' matching output with type 'unsigned int' R0(A,B,C,D,X( 0), 3,0); HOST_c2l(data,l); X( 2)=l; ^~~~~~~~~~~~~~~~~~~~~~ In this case, the OpenSSL developers chose to explicitly cast 'a' to 'unsigned int' (see ).