Hi, so far this issue is not resolved. Sadly the argument is that I/we probably do not handle the return type of libffi correctly. Let me explain the problem (again). For instance in the test [1] the case lltype.FuncType([rffi.Short, rffi.Short], rffi.Short). Here is what happens step by step (if not readable in the mail see [3]): jit compiles trace: <trace call> -- parameter (1213,1213) both 64-bit | v ffi_closure_SYSV | v ffi_closure_helper_SYSV (1) | v < enters ctypes> closure_fcn <callback.c> | v _CallPythonObject <callback.c> | v <calls the python function that returns 1213+1213 = 2426 as 64bit integer> (2) | v <calls h_set [2]. good, because we instructed it to do this> (3) contents of the buffer of (1) before the call: 0xdeadbeefdeadbeef contents of the buffer of (1) after the call: 0xdeadbeefdead097a || vv returns every frame back to <trace call> and saves 0xdeadbeefdead097a in the variable e.g. i42 = call_i(..., 1213, 1213) (1) provides the stack location (3) writes the result to (2) leads into ll2types.py internal_callback and returns 2426L My understanding is that: libffi expects that <trace call> should, just after returning the 64 bit value, cast the result to a 16 bit value. We cannot do that! AFAIK the jit has no notion of a narrower integer type than the machine register. The only exception is loading and storing from/to memory that are later sign extended. Any suggestions? Cheers, Richard [1] rpython/jit/backend/test/runner_test.py:test_call [2] https://github.com/python/cpython/blob/1fe0fd9feb6a4472a9a1b186502eb9c0b2366... [3] http://paste.pound-python.org/show/hvcqL68eqUApEH0PhnuG/