From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 97736 invoked by alias); 8 Nov 2018 09:45:49 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 97717 invoked by uid 89); 8 Nov 2018 09:45:48 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=Its, doubts, behaving, facts X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 08 Nov 2018 09:45:46 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 5407656117; Thu, 8 Nov 2018 04:45:45 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 3ucEiv2wzsjm; Thu, 8 Nov 2018 04:45:45 -0500 (EST) Received: from free.home (tron.gnat.com [IPv6:2620:20:4000:0:46a8:42ff:fe0e:e294]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by rock.gnat.com (Postfix) with ESMTPS id EEA6A560BD; Thu, 8 Nov 2018 04:45:44 -0500 (EST) Received: from livre (livre.home [172.31.160.2]) by free.home (8.15.2/8.15.2) with ESMTP id wA89jVBP013611; Thu, 8 Nov 2018 07:45:32 -0200 From: Alexandre Oliva To: JonY <10walls@gmail.com> Cc: NightStrike , "Joseph S. Myers" , GCC Patches Subject: Re: introduce --enable-mingw-full32 to default to --large-address-aware References: <18c16bb7-c54f-f086-0e90-f06345be10d8@gmail.com> <5ba2e87d-b49e-195d-8fbb-62e992c681c1@gmail.com> <9893706a-37ac-8290-bb7b-1cf2f562ed77@gmail.com> <5704d23a-37d1-4cc7-c131-7dac969d1635@gmail.com> Date: Thu, 08 Nov 2018 09:45:00 -0000 In-Reply-To: <5704d23a-37d1-4cc7-c131-7dac969d1635@gmail.com> (JonY's message of "Wed, 7 Nov 2018 12:49:50 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2018-11/txt/msg00525.txt.bz2 On Nov 7, 2018, JonY <10walls@gmail.com> wrote: > On 11/07/2018 08:34 AM, Alexandre Oliva wrote: >> On Nov 1, 2018, JonY wrote: >>=20 >>> Looks like it causes an error on 64bit: >>> /usr/libexec/gcc/x86_64-w64-mingw32/ld: unrecognized option >>> '--large-address-aware' >>=20 >> What does? The patch I suggested? The current trunk? >>=20 >> What was the command in this case? How was the toolchain configured? > No it's just a quick test to see how x86_64-w64-mingw32 reacts to > --large-address-aware, it doesn't play well. I understand, but you're getting a different result from what I am, I'd like to understand why before attempting to "fix" something that AFAICT is correct and behaving just as intended. Maybe there are valid reasons to drop --large-address-aware altogether on x86_64-w64-mingw32, but I'd like to understand why, as in, how the error above came about for you, when it didn't for me. I built gcc and binutils in a single tree, with x86_64-w64-mingw32 as the target, and the resulting linker would accept --large-address-aware in the -mi386-pe emulation, and that emulation was explicitly enabled when building -m32 binaries. Does your w64 toolchain deviate from any of these facts? > x86_64-mingw32 is not used as far as I know, only with "w64" or "pc". x86_64-mingw32's canonical form is x86_64-pc-mingw32, and they're equivalent, so whatever you say or know about the latter should apply to the shorter form as well. Likewise, my questions and doubts about the shorter form apply equally to the canonical one. > The "w64" carries a special meaning to gcc dating back to the early > 64bit port. It basically tells gcc to use mingw-w64 specific features > that are not found on the regular mingw.org CRT at the time. I see. So -pc- and -w64- are not supposed to be equivalent indeed. Thanks. > This might be affecting the "pc" vendor build, can you check > x86_64-pc-mingw32 just to see if it is affected? I did. Its -m32 mode seems broken to me. As I wrote, the linker emulation is never specified, so it would build 64-bit binaries even when given -m32. Because it lacks explicit linker emulation specification, it can't have --large-address-aware specified either. In my link tests, i686-mingw32 and x86_64-w64-mingw32 both worked (in that their respective linkers wouldn't reject the --large-address-aware passed by gcc) with the --large-address-aware patch that is installed in trunk. Ditto with the incremental patch I posted last week, that would have only improved x86_64-pc-mingw32. --=20 Alexandre Oliva, freedom fighter https://FSFLA.org/blogs/lxo Be the change, be Free! FSF Latin America board member GNU Toolchain Engineer Free Software Evangelist Hay que enGNUrecerse, pero sin perder la terGNUra jam=C3=A1s-GNUChe