From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 109388 invoked by alias); 7 Nov 2018 12:50:19 -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 109372 invoked by uid 89); 7 Nov 2018 12:50:17 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=H*r:sk:p6-v6so, (unknown) X-HELO: mail-pl1-f179.google.com Received: from mail-pl1-f179.google.com (HELO mail-pl1-f179.google.com) (209.85.214.179) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 07 Nov 2018 12:50:14 +0000 Received: by mail-pl1-f179.google.com with SMTP id p6-v6so7826642pll.4 for ; Wed, 07 Nov 2018 04:50:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:cc:references:from:openpgp:autocrypt:subject:message-id:date :user-agent:mime-version:in-reply-to; bh=SctuA7Yv8mohMllxsEZW39lcHceTMRH1UH1ad+E1mh0=; b=RY1Y2rUpsRPDvFa3WjKoser8xyBOIitLM+QJlk6J3dxDLuFLdSVpUnupQyvx3WDxof py8+eUUQObfbefzxKhov5T70sawizYNs53LAWO9p/DK73G/ziOJZrz04km4UAiXF5Bx/ gauNyd+gxM3tNqrHkHX7LnPIz6tTuGHEfnzPCXo8bYoib+EM5ueEdNtZv09vbiB+yHHk vpHzFa1JOnud3XI6WkcBGa9ASOvBU2RJ6M5+ug7oAXKP/W3brTAglI6ia0POZcSkFEB3 4ZjX7CnYnmK0uoiqih1D+9DOq5+cKiXTJtIX6CsGxGWg3lyhkU7qGo6q4zoAUg/fk9xL n2Ng== Return-Path: <10walls@gmail.com> Received: from ?IPv6:2001:e68:4075:c708:f64d:30ff:fe63:5a5a? ([2001:e68:4075:c708:f64d:30ff:fe63:5a5a]) by smtp.gmail.com with ESMTPSA id p62-v6sm612857pfp.111.2018.11.07.04.50.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Nov 2018 04:50:12 -0800 (PST) To: Alexandre Oliva Cc: NightStrike , "Joseph S. Myers" , GCC Patches References: <18c16bb7-c54f-f086-0e90-f06345be10d8@gmail.com> <5ba2e87d-b49e-195d-8fbb-62e992c681c1@gmail.com> <9893706a-37ac-8290-bb7b-1cf2f562ed77@gmail.com> From: JonY <10walls@gmail.com> Openpgp: preference=signencrypt Subject: Re: introduce --enable-mingw-full32 to default to --large-address-aware Message-ID: <5704d23a-37d1-4cc7-c131-7dac969d1635@gmail.com> Date: Wed, 07 Nov 2018 12:50:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="c7DD9eeDmH9WtG2fXExw1ESONwXUBAJMB" X-IsSubscribed: yes X-SW-Source: 2018-11/txt/msg00439.txt.bz2 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --c7DD9eeDmH9WtG2fXExw1ESONwXUBAJMB Content-Type: multipart/mixed; boundary="d4G7AebTwSUNbfLFr99QQFQ5zAeb98IeZ"; protected-headers="v1" From: JonY <10walls@gmail.com> To: Alexandre Oliva Cc: NightStrike , "Joseph S. Myers" , GCC Patches Message-ID: <5704d23a-37d1-4cc7-c131-7dac969d1635@gmail.com> 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> In-Reply-To: --d4G7AebTwSUNbfLFr99QQFQ5zAeb98IeZ Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Content-length: 2727 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? >=20 >=20 > I've been looking into this, getting progressively puzzled, though I > actually managed to duplicated the problem you mentioned, but only on > x86_64-mingw32, NOT on x86_64-w64-mingw32. >=20 >=20 No it's just a quick test to see how x86_64-w64-mingw32 reacts to --large-address-aware, it doesn't play well. > Here's what I found out in my investigation: >=20 > configured for i686-mingw32, GNU ld supports only the i386pe emulation, > that supports the --large-address-aware flag. >=20 > Configured for x86_64-*-mingw32, it supports i386pe, but it defaults to > i386pep, the 64-bit binary format, that does NOT support > --large-address-aware. >=20 > x86_64-w64-mingw32 passes -mi386pe or -mi386pep to the linker, depending > on -m32 or -m64, so the code to pass --large-address-aware to link -m32 > binaries in mingw-w64.h looks correct to me. But x86_64-mingw32 does > NOT use that: it uses the LINK_SPEC from mingw32.h, so it doesn't > specify the emulation, ever. That seems awfully broken to me. If you > ask for a 32-bit binary, using the default 64-bit linker format is > unlikely to produce the desired results. >=20 > Is x86_64-mingw32 really supposed to be a usable target name? It might > even work as a 64-bit only target, but I don't see how its biarch > support could possibly be functional. >=20 > If it is to be usable, is it really supposed to be different from > x86_64-w64-mingw32? Using mingw-w64.h besides mingw32.h would fix the > biarch problems, but perhaps that's not desired for other reasons. >=20 > Fixing that is way beyond my knowledge or interest on Windows-based > platforms, but given clarification as to whether x86_64-mingw32 is > supposed to support biarch at all, I might be able to fix the > implementation of --enable-large-address-aware there. >=20 > As for the problem you reported on x86_64-w64-mingw32, I'm afraid I'll > need some more information to be able to duplicate that and try to fix > it. >=20 > Thanks, >=20 x86_64-mingw32 is not used as far as I know, only with "w64" or "pc". 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. This might be affecting the "pc" vendor build, can you check x86_64-pc-mingw32 just to see if it is affected? Thanks. --d4G7AebTwSUNbfLFr99QQFQ5zAeb98IeZ-- --c7DD9eeDmH9WtG2fXExw1ESONwXUBAJMB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" Content-length: 833 -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEE5QrdnbBX9Ppk4bbPcTtf4pwUXUUFAlvi324ACgkQcTtf4pwU XUVtJg//Y1wTFk87Z6r1AXdLoSJJdcq3vpmwGKcdOEjD6IOZ6SLU1o2X/7ZADbnp Gm0ZojheTJ6jqoK5wHuXJW/7mGnBHBwIZTTUQIhFaBCEmZacr7PEPfo9NNDStAVV 2gIgpDdhtTZQz32j3/YMNcgLhAvFheMqp2ObswXRRzcA7zQRiUqcAAttKyRqN2Kl YETlUUmsNS/mBSSM5/IKHXl1snr8X8EdsDhUE8riH4YdIE1rFZP1X9ZzFY0nb7h+ 1TLDe6EZetgx6tsc9Bs0fFYJF+vLcq2zPZrNq/tlFwgUeLoXwBIUY1sLwTM1uOaQ OKu8D9kVERxRRg/MuiBUtzBjz0ZNyz0ONZSARwHh0513N2YCoQI9shq2B4/+bC5J Jia5yi6Etr5stV8Gw5fMYtn9fWrjy1WtcvdnPeL3u9Bf2lmFg2PBb7J4uvm8fG0P +zrvr2HLQF/59297rvZWCJueQGfsUqCpme8bwzIGjLaY8WlHU74h8/mQpRkaIz5d PDUgfJojnX/a/1QfkJCkALGdX6e5yfvAVIc8n6cixZG1D9qBFGn6ULO+epCpOQqb 96zCHYQ9X0ENIUqM9EX0g3gyURVWce617IAv1zJ+MleNVAdIyRsgKsgwldglYFDA LwRPYG/da0eVYzKzpIP4YfOfp6/28gghF1rVVa24IM2nfOSIXOQ= =YOKt -----END PGP SIGNATURE----- --c7DD9eeDmH9WtG2fXExw1ESONwXUBAJMB--