On Tue, Feb 10, 2015 at 1:20 PM, Richard Henderson wrote:
> On 02/10/2015 11:02 AM, Andrew Pinski wrote:
>> +#define FFI_SIZEOF_JAVA_RAW 4
>
> Since aarch64 doesn't implement the raw java api, this is irrelevant.
Ok. This is what I applied to GCC after testing it (I don't have
access to the lib
On 02/10/2015 11:02 AM, Andrew Pinski wrote:
> +#define FFI_SIZEOF_JAVA_RAW 4
Since aarch64 doesn't implement the raw java api, this is irrelevant.
r~
On Tue, Feb 10, 2015 at 10:35 AM, Richard Henderson wrote:
> On 02/09/2015 12:40 AM, Andrew Pinski wrote:
>> #ifndef LIBFFI_ASM
>> +#ifdef __ILP32__
>> +typedef unsigned long long ffi_arg;
>> +typedef signed long long ffi_sarg;
>> +#else
>
> You need to set FFI_SIZEOF_ARG too.
>
> Otherwise it lo
On 02/09/2015 12:51 AM, Andrew Haley wrote:
> Would it make more sense to use int64_t rather than long long?
Probably, but we should do that all over libffi, rather than just this one hunk.
r~
On 02/09/2015 12:40 AM, Andrew Pinski wrote:
> #ifndef LIBFFI_ASM
> +#ifdef __ILP32__
> +typedef unsigned long long ffi_arg;
> +typedef signed long long ffi_sarg;
> +#else
You need to set FFI_SIZEOF_ARG too.
Otherwise it looks ok.
r~
On 09/02/15 08:40, Andrew Pinski wrote:
> For ILP32, we need to use long long types for ffi_arg and ffi_sarg.
> And then we need to fix up the closure code to load cif, fn, and
> user_data by 32bit instead of 64bits as they are stored as pointers in
> C code.
Would it make more sense to use int64_