This is the mail archive of the java-patches@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] interpreter use of closures and return types


Hi,

On 2016-06-22 11:54, Matthew Fortune wrote:
> Hi,
> 
> While working on getting mips64el support in place for Debian we found a
> bug relating to libgcj/libffi and closures for MIPS n32 and n64. The bug
> is essentially that return types <= 32bit do not end up correctly sign
> extended in registers when a function is called via a closure. A test case
> showing what I think the problem boils down to is at the end of this email.
> Switch between the two lines in foo_binding to see the difference. Note
> that this will not fail on x86 but I believe it will fail on any big endian
> architecture.
> 
> The root of the problem seems to be in a oddity of FFI that integer return
> values less than word (or rather register) size are returned as an ffi_arg.
> The java interpreter does not appear to adhere to this and the patch below
> seems to fix the issue. Can anyone comment if this looks like the right
> approach?
> 
> I think there may be a similar issue in the lang/reflect/natVMProxy.cc
> code (unbox function) by code inspection alone but haven't investigated
> further.
> 
> If this looks OK I'll do some full testsuite runs.

I have been testing Matthew's patch in the last days. I confirm this
patch correctly fixes the original issue I reported him, the fact that
the Arrays.sort() method sort arrays incorrectly. This in turns cause
ecj to fail finding most of the identifiers. With this patch I can use
ecj and rebuild it with itself without any problem.

Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]