public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
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 --]

  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).