From: JonY <10walls@gmail.com>
To: Alexandre Oliva <oliva@adacore.com>
Cc: NightStrike <nightstrike@gmail.com>,
"Joseph S. Myers" <joseph@codesourcery.com>,
GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: introduce --enable-mingw-full32 to default to --large-address-aware
Date: Thu, 01 Nov 2018 10:48:00 -0000 [thread overview]
Message-ID: <9893706a-37ac-8290-bb7b-1cf2f562ed77@gmail.com> (raw)
In-Reply-To: <ork1lxspuw.fsf@lxoliva.fsfla.org>
[-- Attachment #1.1: Type: text/plain, Size: 2490 bytes --]
On 10/31/2018 10:39 PM, Alexandre Oliva wrote:
> On Oct 12, 2018, Alexandre Oliva <oliva@adacore.com> wrote:
>
>> * config/i386/mingw32.h (LINK_SPEC_LARGE_ADDR_AWARE): Define,
>> based on MINGW_DEFAULT_LARGE_ADDR_AWARE.
>> (LINK_SPEC): Insert it.
>> * config/i386/mingw-264.h: Likewise.
> ^ s/2/w/, fixing...
>
> Now, it occurred to me that it is possible for biarch64.h to be
> included, thus enabling 64-bit mode even by default, without including
> mingw-w64.h. I had assumed in my patch that this was not supposed to
> happen, but configuring with --target=x86_64-mingw32 shows it does
> happen, and such a toolchain may (after my patch) pass
> --large-address-aware to the linker, even when linking -m64 binaries.
>
> Is that target configuration really supposed to be different from
> x86_64-w64-mingw32 (or however else the w64 configuration is supposed to
> be spelled), or should x86_64-mingw32 also use mingw-w64.h so that
> they're equivalent?
>
> It seems to me that we need a further patch like this:
>
> diff --git a/gcc/config/i386/mingw32.h b/gcc/config/i386/mingw32.h
> index c9d8a7a31f30..848eb8430b30 100644
> --- a/gcc/config/i386/mingw32.h
> +++ b/gcc/config/i386/mingw32.h
> @@ -114,11 +114,17 @@ along with GCC; see the file COPYING3. If not see
> #define SUBTARGET_EXTRA_SPECS \
> { "shared_libgcc_undefs", SHARED_LIBGCC_UNDEFS_SPEC }
>
> -#if MINGW_DEFAULT_LARGE_ADDR_AWARE
> +#if ! MINGW_DEFAULT_LARGE_ADDR_AWARE
> +# define LINK_SPEC_LARGE_ADDR_AWARE ""
> +#elif ! TARGET_BI_ARCH
> # define LINK_SPEC_LARGE_ADDR_AWARE \
> "%{!shared:%{!mdll:--large-address-aware}}"
> +#elif TARGET_64BIT_DEFAULT
> +# define LINK_SPEC_LARGE_ADDR_AWARE \
> + "%{!shared:%{!mdll:%{m32:--large-address-aware}}}"
> #else
> -# define LINK_SPEC_LARGE_ADDR_AWARE ""
> +# define LINK_SPEC_LARGE_ADDR_AWARE \
> + "%{!shared:%{!mdll:%{!m64:--large-address-aware}}}"
> #endif
>
> #define LINK_SPEC "%{mwindows:--subsystem windows} \
>
> But then, even this wouldn't necessarily do the right thing if e.g.
> biarchx32.h is in effect. Is that even possible?
>
> Or can we just leave mingw32.h as is, considering that (AFAIK) -m64 *is*
> --large-address-aware, it just has that enabled by default?
>
Looks like it causes an error on 64bit:
/usr/libexec/gcc/x86_64-w64-mingw32/ld: unrecognized option
'--large-address-aware'
So it'll need to be excluded for x86_64.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2018-11-01 10:48 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-05 6:48 Alexandre Oliva
2018-10-05 16:40 ` Joseph Myers
2018-10-09 6:38 ` Alexandre Oliva
2018-10-09 11:31 ` JonY
2018-10-10 4:58 ` Alexandre Oliva
2018-10-10 5:20 ` JonY
2018-10-10 8:00 ` Alexandre Oliva
2018-10-11 0:18 ` JonY
2018-10-11 7:46 ` NightStrike
2018-10-11 11:32 ` JonY
2018-10-12 6:28 ` Alexandre Oliva
2018-10-12 11:27 ` JonY
[not found] ` <ork1lxspuw.fsf@lxoliva.fsfla.org>
2018-11-01 10:48 ` JonY [this message]
2018-11-07 11:59 ` Alexandre Oliva
2018-11-07 12:50 ` JonY
2018-11-08 9:45 ` Alexandre Oliva
2018-11-08 15:39 ` JonY
2018-11-09 10:49 ` Alexandre Oliva
2018-11-09 12:22 ` JonY
2018-10-07 8:03 ` JonY
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9893706a-37ac-8290-bb7b-1cf2f562ed77@gmail.com \
--to=10walls@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=joseph@codesourcery.com \
--cc=nightstrike@gmail.com \
--cc=oliva@adacore.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).