svn commit: r211505 - head/contrib/gcc

[Dimitry Andric]

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 <http://cvs.openssl.org/chngview?cn=19818>).