search for: issue13370

...t; types narrower than int are promoted to int on all architectures. > Nobody has actually noticed any issues with this before now, as far as > I know. The only reason that I noticed was that Python ctypes started misbehaving when we went to build/test it on OS X Lion (http://bugs.python.org/issue13370). After investigating the failure I found this. Python uses libffi and libffi implements the GCC ABI. So I would expect any project using libffi with clang to have problems. > If gcc has decided to assume no sign/zero-extension on x86-64, we need > to follow their lead, at least on Linux....

...int are promoted to int on all architectures. >> Nobody has actually noticed any issues with this before now, as far as >> I know. > > The only reason that I noticed was that Python ctypes started misbehaving > when we went to build/test it on OS X Lion (http://bugs.python.org/issue13370). > After investigating the failure I found this. Python uses libffi and > libffi implements > the GCC ABI. So I would expect any project using libffi with clang to > have problems. > >> If gcc has decided to assume no sign/zero-extension on x86-64, we need >> to follo...

On Wed, Feb 8, 2012 at 6:49 PM, Meador Inge <meadori at gmail.com> wrote: > I recently noticed a difference between the way GCC and LLVM treat > sign extension for parameters and return values on x86-64.  I could > not find a clear answer in the x86-64 ABI [1] concerning whether > parameters should be sign extended by the caller or callee and > similarly whether return values

I recently noticed a difference between the way GCC and LLVM treat sign extension for parameters and return values on x86-64. I could not find a clear answer in the x86-64 ABI [1] concerning whether parameters should be sign extended by the caller or callee and similarly whether return values should be sign extended by the caller or callee. Consider a simple 'signed char' division