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>). _______________________________________________ svn-src-head@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
