From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 40992 invoked by alias); 2 Jan 2018 09:58:36 -0000 Mailing-List: contact java-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-owner@gcc.gnu.org Received: (qmail 40981 invoked by uid 89); 2 Jan 2018 09:58:36 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,KAM_SHORT,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=H*f:sk:3BC7510, MiB, alright, H*i:FON4AH4v5nw X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 02 Jan 2018 09:58:34 +0000 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id CF105356D6; Tue, 2 Jan 2018 09:58:33 +0000 (UTC) Received: from zebedee.pink (ovpn-116-253.phx2.redhat.com [10.3.116.253]) by smtp.corp.redhat.com (Postfix) with ESMTP id EFB745D755; Tue, 2 Jan 2018 09:58:32 +0000 (UTC) Subject: Re: add support for x86_64-w64-mingw32 and cut the fat from libgcj To: Yale Zhang , Brian Jones Cc: java@gcc.gnu.org References: <3BC75108-7D53-4CCB-AFEF-51C8EC98F9B3@gmail.com> From: Andrew Haley Message-ID: <6a6ed9c1-bd53-3106-b257-a68c7d5e0351@redhat.com> Date: Tue, 02 Jan 2018 09:58:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2018-01/txt/msg00004.txt.bz2 On 01/01/18 21:03, Yale Zhang wrote: > Alright, I've submitted my request & patch to bugzilla: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83647 > > "Having said that, I'm quite happy to accept mingw patches if there is a > live branch to apply them to." > Under the target version, I saw a tentative 6.4.1, so there still could be > hope this can make it into GCC 6. > > > I also did the experiment of compiling libgcj with -ffunction-sections > -fdata-sections and then use --gc-sections when linking to see if that > helps remove dead code. Somehow, that instead increased the size of a > simple test program (with multithreading & sockets) from 4.54 to 4.72 MiB. I'm not surprised. All Java code is reachable from everywhere because of reflection and class loaders. You can't simply use --gc-sections because code called reflectively would fail at runtime. > "I was hoping to keep GCJ up to date to use it for OpenJDK bootstrapping" > That paranoid? Why not use the minimal Eclipse Java compiler which > Classpath uses for bootstrapping? It sounds like ECJ can't be trusted if it > was compiled with an untrusted/unknown compiler. Indeed. If Programming Language X is written in X, you're going to need the previous version of X to build it. It's so for C and for Java. We have a string of versions of OpenJDK going back to Version 6, and that was compiled with GCJ. So, there's nothing to stop someone from digging out OpenJDK 6, building that with an old GCJ, and spooling forward to today. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671