[Bug middle-end/63793] New: -mcmodel=medium in gfortran on x86_64 emits references that are RIP relative (instead of using the GOT)

[Bug middle-end/63793] New: -mcmodel=medium in gfortran on x86_64 emits references that are RIP relative (instead of using the GOT)

[howarth at bromo dot med.uc.edu]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 6450 bytes --]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63793

            Bug ID: 63793
           Summary: -mcmodel=medium in gfortran on x86_64 emits references
                    that are RIP relative (instead of using the GOT)
           Product: gcc
           Version: 4.9.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: howarth at bromo dot med.uc.edu

The src_flexwrf_v3.1 package from
http://flexpart.eu/downloads/src_flexwrf_v3.1.tar.gz fails to link on x86_64
darwin when compiled with the required -mcmodel=medium option due to a code
generation bug that the darwin linker fails on. The offending file is compiled
with...

gfortran -c -I/sw/include -fno-common -mcmodel=medium -fconvert=little-endian
-finit-local-zero -fno-range-check convmix_kfeta.f90

and the linkage later fails as...

gfortran *.o -o flexwrf31_gnu_serial -L/sw/lib -fno-common -mcmodel=medium
-fconvert=little-endian -finit-local-zero -fno-range-check -L/sw/lib -lnetcdff 
final section layout:
    __TEXT/__text addr=0x1000017F5, size=0x00126A11, fileOffset=0x000017F5,
type=1
    __TEXT/__stubs addr=0x100128206, size=0x0000023A, fileOffset=0x00128206,
type=28
    __TEXT/__stub_helper addr=0x100128440, size=0x000003C6,
fileOffset=0x00128440, type=32
    __TEXT/__cstring addr=0x100128808, size=0x00000B97, fileOffset=0x00128808,
type=13
    __TEXT/__const addr=0x1001293A0, size=0x0000A6BC, fileOffset=0x001293A0,
type=0
    __TEXT/__eh_frame addr=0x100133A60, size=0x00004598, fileOffset=0x00133A60,
type=19
    __DATA/__got addr=0x100138000, size=0x000002B8, fileOffset=0x00138000,
type=29
    __DATA/__nl_symbol_ptr addr=0x1001382B8, size=0x00000010,
fileOffset=0x001382B8, type=29
    __DATA/__la_symbol_ptr addr=0x1001382C8, size=0x000002F8,
fileOffset=0x001382C8, type=27
    __DATA/__data addr=0x1001385C0, size=0x000008F0, fileOffset=0x001385C0,
type=0
    __DATA/__common addr=0x100138EC0, size=0x000000EC, fileOffset=0x00000000,
type=25
    __DATA/__bss5 addr=0x100138FC0, size=0x00000070, fileOffset=0x00000000,
type=25
    __DATA/__pu_bss5 addr=0x100139040, size=0x000017F0, fileOffset=0x00000000,
type=25
    __DATA/__bss6 addr=0x10013A840, size=0x00855AF4, fileOffset=0x00000000,
type=25
    __DATA/__pu_bss2 addr=0x100990334, size=0x0000047C, fileOffset=0x00000000,
type=25
    __DATA/__pu_bss6 addr=0x1009907C0, size=0x01EBCAA8, fileOffset=0x00000000,
type=25
    __DATA/__pu_bss3 addr=0x10284D268, size=0x00000010, fileOffset=0x00000000,
type=25
    __DATA/__pu_bss4 addr=0x10284D280, size=0x0000001C, fileOffset=0x00000000,
type=25
    __DATA/__bss2 addr=0x10284D29C, size=0x00000020, fileOffset=0x00000000,
type=25
    __DATA/__huge addr=0x10284D2C0, size=0x129E8DD40, fileOffset=0x00000000,
type=25
ld: 32-bit RIP relative reference out of range (4246534707 max is +/-4GB): from
_convmix_kfeta_ (0x100058E3C) to _sumpartgrid.2471 (0x1FD229580) in
'_convmix_kfeta_' from convmix_kfeta.o for architecture x86_64
collect2: error: ld returned 1 exit status

The darwin linker developer has provided the following analysis of this bug...

-----------------------------------------------------------------------------------

This is a little known aspect of x86_64 mach-o that allows the use of the small
code model everywhere (that is not need a large code model).  When the compiler
references “large” ( >= 1MB) zero-fill data, it should do it through the GOT
(instead of direct RIP relative reference).  

When the linker lays out the output, if it is bigger than 2GB, it moves all
large zero-fill symbols to a new __DATA,__huge section which the linker puts
last.  As long as all the uses of moved large data is through the GOT, this
just works and you can have very large mach-o binaries. 

In this case the file from convmix_kfeta.o defines _sumpartgrid.2471  (which is
a 4MB zero-fill symbol) but that same file  has a reference to
_sumpartgrid.2471 from the function _convmix_kfeta_ that is RIP relative
(instead of using the GOT).
>From gcc-bugs-return-466123-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Nov 09 14:19:36 2014
Return-Path: <gcc-bugs-return-466123-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 25729 invoked by alias); 9 Nov 2014 14:19:35 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 25685 invoked by uid 48); 9 Nov 2014 14:19:31 -0000
From: "howarth at bromo dot med.uc.edu" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/63793] -mcmodel=medium in gfortran on x86_64 emits references that are RIP relative (instead of using the GOT)
Date: Sun, 09 Nov 2014 14:19:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 4.9.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: howarth at bromo dot med.uc.edu
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: attachments.created
Message-ID: <bug-63793-4-xVB6xB9Kun@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63793-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63793-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-11/txt/msg00595.txt.bz2
Content-length: 419

https://gcc.gnu.org/bugzilla/show_bug.cgi?idc793

--- Comment #1 from howarth at bromo dot med.uc.edu ---
Created attachment 33927
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id3927&actioníit
assembly file for convex_kfeta.s on x86_64 darwin14

Generated with "gfortran -c -I/sw/include -fno-common -mcmodel=medium
-fconvert=little-endian -finit-local-zero -fno-range-check convmix_kfeta.f90
--save-temps"

[Bug middle-end/63793] -mcmodel=medium in gfortran on x86_64 emits references that are RIP relative (instead of using the GOT)

[howarth at bromo dot med.uc.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63793

--- Comment #2 from howarth at bromo dot med.uc.edu ---
Unfortunately, due to the number of modules required by convex_kfeta.f90, it is
impossible to create a small test case. However this problem can be reproduced
by downloading the src_flexwrf_v3.1.tar.bz2 source code and executing...

make -f makefile.mom serial

[Bug middle-end/63793] -mcmodel=medium in gfortran on x86_64 emits references that are RIP relative (instead of using the GOT)

[howarth at bromo dot med.uc.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63793

--- Comment #3 from howarth at bromo dot med.uc.edu ---
Note that the default makefile.mom in the source tarball can be linked against
the libnetcdff installed from the fink (http://finkproject.org)
netcdf-fortran7/netcdf-fortran7-shlibs packages.

[Bug middle-end/63793] -mcmodel=medium in gfortran on x86_64 emits references that are RIP relative (instead of using the GOT)

[howarth at bromo dot med.uc.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63793

--- Comment #4 from howarth at bromo dot med.uc.edu ---
The offending instructions can be seen with...

% grep _sumpartgrid.2471 convmix_kfeta.s
    leaq    _sumpartgrid.2471(%rip), %rax
    leaq    _sumpartgrid.2471(%rip), %rax
    leaq    _sumpartgrid.2471(%rip), %rdx
    leaq    _sumpartgrid.2471(%rip), %rdx
    leaq    _sumpartgrid.2471(%rip), %rdx
    .zerofill __DATA,__bss6,_sumpartgrid.2471,4000000,6

[Bug middle-end/63793] -mcmodel=medium in gfortran on x86_64 emits references that are RIP relative (instead of using the GOT)

[howarth at bromo dot med.uc.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63793

--- Comment #5 from howarth at bromo dot med.uc.edu ---
Checking this issue with current gcc trunk on x86_64 linux, I see differently
handling of sumpartgrid in the emitted assembly...

$ grep sumpartgrid convmix_kfeta.s
    movabsq    $sumpartgrid.3500@GOTOFF, %rax
    movabsq    $sumpartgrid.3500@GOTOFF, %rax
    movabsq    $sumpartgrid.3500@GOTOFF, %rdx
    movabsq    $sumpartgrid.3500@GOTOFF, %rdx
    movabsq    $sumpartgrid.3500@GOTOFF, %rdx
    .local    sumpartgrid.3500
    .largecomm    sumpartgrid.3500,4000000,64

for -mcmodel=medium

[Bug middle-end/63793] -mcmodel=medium in gfortran on x86_64 emits references that are RIP relative (instead of using the GOT)

[howarth at bromo dot med.uc.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63793

--- Comment #6 from howarth at bromo dot med.uc.edu ---
This may be where the usage of @GOTOFF was introduced for -mcmodel=medium...

https://gcc.gnu.org/ml/gcc-patches/2005-07/msg00046.html
https://gcc.gnu.org/ml/gcc-patches/2005-07/msg01134.html
https://gcc.gnu.org/ml/gcc-patches/2005-07/msg01593.html

[Bug middle-end/63793] -mcmodel=medium in gfortran on x86_64 emits references that are RIP relative (instead of using the GOT)

[howarth at bromo dot med.uc.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63793

--- Comment #7 from howarth at bromo dot med.uc.edu ---
This seems to be due to the fact that on x86_64 linux, auto-host.h contains...

/* Define true if the assembler supports '.long foo@GOTOFF'. */
#ifndef USED_FOR_TARGET
#define HAVE_AS_GOTOFF_IN_DATA 1
#endif

but on x86_64 darwin, we have...

/* Define true if the assembler supports '.long foo@GOTOFF'. */
#ifndef USED_FOR_TARGET
#define HAVE_AS_GOTOFF_IN_DATA 0
#endif

[Bug middle-end/63793] -mcmodel=medium in gfortran on x86_64 emits references that are RIP relative (instead of using the GOT)

[howarth at bromo dot med.uc.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63793

--- Comment #8 from howarth at bromo dot med.uc.edu ---
It appears the two instances of the use of HAVE_AS_GOTOFF_IN_DATA are in
gcc/config/i386/i386.c

void
ix86_output_addr_diff_elt (FILE *file, int value, int rel)
{
  const char *directive = ASM_LONG;

#ifdef ASM_QUAD
  if (TARGET_64BIT && CASE_VECTOR_MODE == DImode)
    directive = ASM_QUAD;
#else
  gcc_assert (!TARGET_64BIT);
#endif
  /* We can't use @GOTOFF for text labels on VxWorks; see gotoff_operand.  */
  if (TARGET_64BIT || TARGET_VXWORKS_RTP)
    fprintf (file, "%s%s%d-%s%d\n",
             directive, LPREFIX, value, LPREFIX, rel);
  else if (HAVE_AS_GOTOFF_IN_DATA)
    fprintf (file, ASM_LONG "%s%d@GOTOFF\n", LPREFIX, value);
#if TARGET_MACHO
  else if (TARGET_MACHO)
    {
      fprintf (file, ASM_LONG "%s%d-", LPREFIX, value);
      machopic_output_function_base_name (file);
      putc ('\n', file);
    }
#endif
  else
    asm_fprintf (file, ASM_LONG "%U%s+[.-%s%d]\n",
                 GOT_SYMBOL_NAME, LPREFIX, value);
}
^L
/* Generate either "mov $0, reg" or "xor reg, reg", as appropriate
   for the target.  */

and in gcc/config/i386/i386.md

(define_expand "tablejump"
  [(parallel [(set (pc) (match_operand 0 "indirect_branch_operand"))
              (use (label_ref (match_operand 1)))])]
  ""
{
  /* In PIC mode, the table entries are stored GOT (32-bit) or PC (64-bit)
     relative.  Convert the relative address to an absolute address.  */
  if (flag_pic)
    {
      rtx op0, op1;
      enum rtx_code code;

      /* We can't use @GOTOFF for text labels on VxWorks;
         see gotoff_operand.  */
      if (TARGET_64BIT || TARGET_VXWORKS_RTP)
        {
          code = PLUS;
          op0 = operands[0];
          op1 = gen_rtx_LABEL_REF (Pmode, operands[1]);
        }
      else if (TARGET_MACHO || HAVE_AS_GOTOFF_IN_DATA)
        {
          code = PLUS;
          op0 = operands[0];
          op1 = pic_offset_table_rtx;
        }
      else
        {
          code = MINUS;
          op0 = pic_offset_table_rtx;
          op1 = operands[0];
        }

      operands[0] = expand_simple_binop (Pmode, code, op0, op1, NULL_RTX, 0,
                                         OPTAB_DIRECT);
    }

[Bug middle-end/63793] -mcmodel=medium in gfortran on x86_64 emits references that are RIP relative (instead of using the GOT)

[howarth at bromo dot med.uc.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63793

--- Comment #9 from howarth at bromo dot med.uc.edu ---
Created attachment 33962
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33962&action=edit
assembly file for convex_kfeta.s on x86_64 linux

Generated with  

gfortran -c -I/home/howarth/dist_netcdf-fortran-4.4.1/include -mcmodel=medium
-fconvert=little-endian -finit-local-zero -fno-range-check  convmix_kfeta.f90
--save-temps

[Bug middle-end/63793] -mcmodel=medium in gfortran on x86_64 emits references that are RIP relative (instead of using the GOT)

[howarth at bromo dot med.uc.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63793

--- Comment #10 from howarth at bromo dot med.uc.edu ---
Jakub, Do you have any insights on where the code generation for darwin would
fork from linux to use %rip rather than @GOTOFF. The darwin linker developer
says for large code (which I assume means both -mcmodel=medium/large), darwin
should be using @GOT rather than %rip. The most obvious places are those using
the conditional HAVE_AS_GOTOFF_IN_DATA which is set to 0 on darwin, but I am
concerned that could be a red herring and we need to look elsewhere in
gcc/config/i386/i386.[c/md].

[Bug middle-end/63793] -mcmodel=medium in gfortran on x86_64 emits references that are RIP relative (instead of using the GOT)

[howarth at bromo dot med.uc.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63793

--- Comment #11 from howarth at bromo dot med.uc.edu ---
FYI, the darwin linker developer had the following comments on @GOTOFF..

> This may be a red herring.
> 
> @GOTOFF is a different concept.  IIRC, the ELF runtime sets of RBX to point
>  to the GOT table.  @GOTOFF is for accessing variables that are a (link time)
> fixed offset in the GOT table.
> 
> Darwin does not support @GOTOFF at all.  Local variables are accessed 
> RIP-rel, or if large, indirectly via @GOT.

However, outside of the sections of gcc/config/i386/i386.[c/md] conditional on
HAVE_AS_GOTOFF_IN_DATA, I don't see any other obvious places where %rip would
be emitted for Mach-O but not linux.

[Bug middle-end/63793] -mcmodel=medium in gfortran on x86_64 emits references that are RIP relative (instead of using the GOT)

[iains at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63793

--- Comment #12 from Iain Sandoe <iains at gcc dot gnu.org> ---
caveat: I have not examined this bug… 

.. but I have the following patch in my Q (solves a problem when GAS is the
assembler).  This should not fire unless the configuration says that the
assembler supports gotoff in data (which GAS does, of course)

Otherwise, I'm not aware of any darwin-specific support for mcmodel= .. no-one
has had time to look at it ...

.. if the patch makes a difference, look for a config error.

---

   gcc_assert (!TARGET_64BIT);
 #endif
   /* We can't use @GOTOFF for text labels on VxWorks; see gotoff_operand.  */
   if (TARGET_64BIT || TARGET_VXWORKS_RTP)
     fprintf (file, "%s%s%d-%s%d\n",
          directive, LPREFIX, value, LPREFIX, rel);
-  else if (HAVE_AS_GOTOFF_IN_DATA)
-    fprintf (file, ASM_LONG "%s%d@GOTOFF\n", LPREFIX, value);
 #if TARGET_MACHO
   else if (TARGET_MACHO)
     {
       fprintf (file, ASM_LONG "%s%d-", LPREFIX, value);
       machopic_output_function_base_name (file);
       putc ('\n', file);
     }
 #endif
+  else if (HAVE_AS_GOTOFF_IN_DATA)
+    fprintf (file, ASM_LONG "%s%d@GOTOFF\n", LPREFIX, value);
   else
     asm_fprintf (file, ASM_LONG "%U%s+[.-%s%d]\n",
          GOT_SYMBOL_NAME, LPREFIX, value);
 }

 /* Generate either "mov $0, reg" or "xor reg, reg", as appropriate
>From gcc-bugs-return-466698-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 14 00:36:03 2014
Return-Path: <gcc-bugs-return-466698-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 25417 invoked by alias); 14 Nov 2014 00:36:03 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 25349 invoked by uid 48); 14 Nov 2014 00:35:59 -0000
From: "howarth at bromo dot med.uc.edu" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/63793] -mcmodel=medium in gfortran on x86_64 emits references that are RIP relative (instead of using the GOT)
Date: Fri, 14 Nov 2014 00:36:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 4.9.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: howarth at bromo dot med.uc.edu
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-63793-4-OBSMOn9vXQ@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63793-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63793-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-11/txt/msg01170.txt.bz2
Content-length: 1376

https://gcc.gnu.org/bugzilla/show_bug.cgi?idc793

--- Comment #13 from howarth at bromo dot med.uc.edu ---
(In reply to howarth from comment #11)
> FYI, the darwin linker developer had the following comments on @GOTOFF..
>
> > This may be a red herring.
> >
> > @GOTOFF is a different concept.  IIRC, the ELF runtime sets of RBX to point
> >  to the GOT table.  @GOTOFF is for accessing variables that are a (link time)
> > fixed offset in the GOT table.
> >
> > Darwin does not support @GOTOFF at all.  Local variables are accessed
> > RIP-rel, or if large, indirectly via @GOT.
>
> However, outside of the sections of gcc/config/i386/i386.[c/md] conditional
> on HAVE_AS_GOTOFF_IN_DATA, I don't see any other obvious places where %rip
> would be emitted for Mach-O but not linux.

Empirically, it seems logical that this bug should be in the section
conditional on HAVE_AS_GOTOFF_IN_DATA because the problematic symbol with the
core name sumpartgrid shows up as in a grep of the assembly as...

    movabsq    $sumpartgrid.3500@GOTOFF, %rax

on linux, while on darwin it shows up as

    leaq    _sumpartgrid.2471(%rip), %rax

I am assuming that the emission of @GOTOFF on linux is entirely under the
control of the HAVE_AS_GOTOFF_IN_DATA conditional and thus should point us at
the section that needs to be enhanced to use &GOT on darwin for
-mcmodel=medium/large.

[Bug middle-end/63793] -mcmodel=medium in gfortran on x86_64 emits references that are RIP relative (instead of using the GOT)

[howarth at bromo dot med.uc.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63793

--- Comment #14 from howarth at bromo dot med.uc.edu ---
(In reply to Iain Sandoe from comment #12)
> caveat: I have not examined this bug… 
> 
> .. but I have the following patch in my Q (solves a problem when GAS is the
> assembler).  This should not fire unless the configuration says that the
> assembler supports gotoff in data (which GAS does, of course)
> 
> Otherwise, I'm not aware of any darwin-specific support for mcmodel= ..
> no-one has had time to look at it ...
> 
> .. if the patch makes a difference, look for a config error.
> 
> ---
> 
>    gcc_assert (!TARGET_64BIT);
>  #endif
>    /* We can't use @GOTOFF for text labels on VxWorks; see gotoff_operand. 
> */
>    if (TARGET_64BIT || TARGET_VXWORKS_RTP)
>      fprintf (file, "%s%s%d-%s%d\n",
>  	     directive, LPREFIX, value, LPREFIX, rel);
> -  else if (HAVE_AS_GOTOFF_IN_DATA)
> -    fprintf (file, ASM_LONG "%s%d@GOTOFF\n", LPREFIX, value);
>  #if TARGET_MACHO
>    else if (TARGET_MACHO)
>      {
>        fprintf (file, ASM_LONG "%s%d-", LPREFIX, value);
>        machopic_output_function_base_name (file);
>        putc ('\n', file);
>      }
>  #endif
> +  else if (HAVE_AS_GOTOFF_IN_DATA)
> +    fprintf (file, ASM_LONG "%s%d@GOTOFF\n", LPREFIX, value);
>    else
>      asm_fprintf (file, ASM_LONG "%U%s+[.-%s%d]\n",
>  		 GOT_SYMBOL_NAME, LPREFIX, value);
>  }
>  
>  /* Generate either "mov $0, reg" or "xor reg, reg", as appropriate

I don't see how this will help. Nick was clear that darwin doesn't support
@GOTOFF and that the problem is that we need to emit @GOT rather than %rip for
large code models (aka 64-bit) per his original comments...

-----------------------------------------------------------------------------------

This is a little known aspect of x86_64 mach-o that allows the use of the small
code model everywhere (that is not need a large code model).  When the compiler
references “large” ( >= 1MB) zero-fill data, it should do it through the GOT
(instead of direct RIP relative reference).  

When the linker lays out the output, if it is bigger than 2GB, it moves all
large zero-fill symbols to a new __DATA,__huge section which the linker puts
last.  As long as all the uses of moved large data is through the GOT, this
just works and you can have very large mach-o binaries. 

In this case the file from convmix_kfeta.o defines _sumpartgrid.2471  (which is
a 4MB zero-fill symbol) but that same file  has a reference to
_sumpartgrid.2471 from the function _convmix_kfeta_ that is RIP relative
(instead of using the GOT).
>From gcc-bugs-return-466701-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Nov 14 00:39:50 2014
Return-Path: <gcc-bugs-return-466701-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 30803 invoked by alias); 14 Nov 2014 00:39:50 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 30778 invoked by uid 48); 14 Nov 2014 00:39:46 -0000
From: "cesar at codesourcery dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/63858] New: fixed form OpenACC directive ICE with -fopenacc -fopenmp
Date: Fri, 14 Nov 2014 00:39:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: cesar at codesourcery dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter
Message-ID: <bug-63858-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-11/txt/msg01173.txt.bz2
Content-length: 626

https://gcc.gnu.org/bugzilla/show_bug.cgi?idc858

            Bug ID: 63858
           Summary: fixed form OpenACC directive ICE with -fopenacc
                    -fopenmp
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: cesar at codesourcery dot com

The attached test case causes gfortran to ICE when -fopenmp is used with
-fopenacc. It looks like there is a problem with the way that continuations are
handled in openmp/openacc directives.

[Bug middle-end/63793] -mcmodel=medium in gfortran on x86_64 emits references that are RIP relative (instead of using the GOT)

[howarth at bromo dot med.uc.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63793

--- Comment #15 from howarth at bromo dot med.uc.edu ---
(In reply to Iain Sandoe from comment #12)

The question arises if this section...

   else if (TARGET_MACHO)
     {
       fprintf (file, ASM_LONG "%s%d-", LPREFIX, value);
       machopic_output_function_base_name (file);
       putc ('\n', file);
     }
 #endif

could even be emitting the...

    leaq    _sumpartgrid.2471(%rip), %rax

as there is no '-' in that assembly output.

[Bug middle-end/63793] -mcmodel=medium in gfortran on x86_64 emits references that are RIP relative (instead of using the GOT)

[howarth at bromo dot med.uc.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63793

--- Comment #16 from howarth at bromo dot med.uc.edu ---
I guess we should also consider the instances of UNSPEC_GOTOFF, no? However I
didn't see anything obvious which was conditional against Mach-O where it was
used.

[Bug middle-end/63793] -mcmodel=medium in gfortran on x86_64 emits references that are RIP relative (instead of using the GOT)

[howarth at bromo dot med.uc.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63793

--- Comment #17 from howarth at bromo dot med.uc.edu ---
The only other place that looks promising is...

    case UNSPEC_GOTOFF:
      /* Refuse GOTOFF in 64bit mode since it is always 64bit when used.
         While ABI specify also 32bit relocation but we don't produce it in
         small PIC model at all.  */
      if ((GET_CODE (XVECEXP (disp, 0, 0)) == SYMBOL_REF
           || GET_CODE (XVECEXP (disp, 0, 0)) == LABEL_REF)
          && !TARGET_64BIT)
        return !TARGET_PECOFF && gotoff_operand (XVECEXP (disp, 0, 0), Pmode);
      return false;

in gcc/config/i386/i386.c. As I understand the problem, we need to expand the
existing code to treat -mcmodel=small in the current manner but
-mcmodel=medium/large needs to switch to GOT.

[Bug middle-end/63793] -mcmodel=medium in gfortran on x86_64 emits references that are RIP relative (instead of using the GOT)

[howarth at bromo dot med.uc.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63793

--- Comment #18 from howarth at bromo dot med.uc.edu ---
Another interesting section of code in gcc/config/i386/i386.c

  else
    {
      /* For TARGET_64BIT and MS_ABI, force pic on, in order to enable the
         use of rip-relative addressing.  This eliminates fixups that
         would otherwise be needed if this object is to be placed in a
         DLL, and is essentially just as efficient as direct addressing.  */
      if (TARGET_64BIT_P (opts->x_ix86_isa_flags)
          && (TARGET_RDOS || TARGET_PECOFF))
        opts->x_ix86_cmodel = CM_MEDIUM_PIC, opts->x_flag_pic = 1;
      else if (TARGET_64BIT_P (opts->x_ix86_isa_flags))
        opts->x_ix86_cmodel = opts->x_flag_pic ? CM_SMALL_PIC : CM_SMALL;
      else
        opts->x_ix86_cmodel = CM_32;
    }