svn commit: r211505 - head/contrib/gcc
Dimitry Andric
dimitry at andric.com
Sat Aug 21 13:59:41 UTC 2010
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>).
More information about the svn-src-all
mailing list