From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 125221 invoked by alias); 22 Jun 2016 16:49:14 -0000 Mailing-List: contact java-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-patches-owner@gcc.gnu.org Received: (qmail 125211 invoked by uid 89); 22 Jun 2016 16:49:13 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=matthews, Matthews, H*r:111, him X-HELO: hall.aurel32.net Received: from hall.aurel32.net (HELO hall.aurel32.net) (195.154.112.97) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Wed, 22 Jun 2016 16:49:03 +0000 Received: from ohm.aurel32.net ([2001:bc8:30d7:111::1000]) by hall.aurel32.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1bFlKl-0001zu-Hh; Wed, 22 Jun 2016 18:48:59 +0200 Received: from aurel32 by ohm.aurel32.net with local (Exim 4.87) (envelope-from ) id 1bFlKd-0003Sm-Rh; Wed, 22 Jun 2016 18:48:51 +0200 Date: Wed, 22 Jun 2016 16:49:00 -0000 From: Aurelien Jarno To: Matthew Fortune Cc: "java-patches@gcc.gnu.org" , Yunqiang Su Subject: Re: [RFC] interpreter use of closures and return types Message-ID: <20160622164851.GA13195@aurel32.net> References: <6D39441BF12EF246A7ABCE6654B023537E45723C@HHMAIL01.hh.imgtec.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6D39441BF12EF246A7ABCE6654B023537E45723C@HHMAIL01.hh.imgtec.org> User-Agent: Mutt/1.6.0 (2016-04-01) X-SW-Source: 2016-q2/txt/msg00023.txt.bz2 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