* [Bug middle-end/63793] -mcmodel=medium in gfortran on x86_64 emits references that are RIP relative (instead of using the GOT)
2014-11-09 14:17 [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
@ 2014-11-09 14:29 ` howarth at bromo dot med.uc.edu
2014-11-09 14:32 ` howarth at bromo dot med.uc.edu
` (14 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: howarth at bromo dot med.uc.edu @ 2014-11-09 14:29 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug middle-end/63793] -mcmodel=medium in gfortran on x86_64 emits references that are RIP relative (instead of using the GOT)
2014-11-09 14:17 [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
2014-11-09 14:29 ` [Bug middle-end/63793] " howarth at bromo dot med.uc.edu
@ 2014-11-09 14:32 ` howarth at bromo dot med.uc.edu
2014-11-09 15:20 ` howarth at bromo dot med.uc.edu
` (13 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: howarth at bromo dot med.uc.edu @ 2014-11-09 14:32 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug middle-end/63793] -mcmodel=medium in gfortran on x86_64 emits references that are RIP relative (instead of using the GOT)
2014-11-09 14:17 [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
2014-11-09 14:29 ` [Bug middle-end/63793] " howarth at bromo dot med.uc.edu
2014-11-09 14:32 ` howarth at bromo dot med.uc.edu
@ 2014-11-09 15:20 ` howarth at bromo dot med.uc.edu
2014-11-13 15:51 ` howarth at bromo dot med.uc.edu
` (12 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: howarth at bromo dot med.uc.edu @ 2014-11-09 15:20 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug middle-end/63793] -mcmodel=medium in gfortran on x86_64 emits references that are RIP relative (instead of using the GOT)
2014-11-09 14:17 [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
` (2 preceding siblings ...)
2014-11-09 15:20 ` howarth at bromo dot med.uc.edu
@ 2014-11-13 15:51 ` howarth at bromo dot med.uc.edu
2014-11-13 16:51 ` howarth at bromo dot med.uc.edu
` (11 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: howarth at bromo dot med.uc.edu @ 2014-11-13 15:51 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug middle-end/63793] -mcmodel=medium in gfortran on x86_64 emits references that are RIP relative (instead of using the GOT)
2014-11-09 14:17 [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
` (3 preceding siblings ...)
2014-11-13 15:51 ` howarth at bromo dot med.uc.edu
@ 2014-11-13 16:51 ` howarth at bromo dot med.uc.edu
2014-11-13 18:03 ` howarth at bromo dot med.uc.edu
` (10 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: howarth at bromo dot med.uc.edu @ 2014-11-13 16:51 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug middle-end/63793] -mcmodel=medium in gfortran on x86_64 emits references that are RIP relative (instead of using the GOT)
2014-11-09 14:17 [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
` (4 preceding siblings ...)
2014-11-13 16:51 ` howarth at bromo dot med.uc.edu
@ 2014-11-13 18:03 ` howarth at bromo dot med.uc.edu
2014-11-13 18:10 ` howarth at bromo dot med.uc.edu
` (9 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: howarth at bromo dot med.uc.edu @ 2014-11-13 18:03 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug middle-end/63793] -mcmodel=medium in gfortran on x86_64 emits references that are RIP relative (instead of using the GOT)
2014-11-09 14:17 [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
` (5 preceding siblings ...)
2014-11-13 18:03 ` howarth at bromo dot med.uc.edu
@ 2014-11-13 18:10 ` howarth at bromo dot med.uc.edu
2014-11-13 21:00 ` howarth at bromo dot med.uc.edu
` (8 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: howarth at bromo dot med.uc.edu @ 2014-11-13 18:10 UTC (permalink / raw)
To: gcc-bugs
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);
}
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug middle-end/63793] -mcmodel=medium in gfortran on x86_64 emits references that are RIP relative (instead of using the GOT)
2014-11-09 14:17 [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
` (6 preceding siblings ...)
2014-11-13 18:10 ` howarth at bromo dot med.uc.edu
@ 2014-11-13 21:00 ` howarth at bromo dot med.uc.edu
2014-11-13 21:04 ` howarth at bromo dot med.uc.edu
` (7 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: howarth at bromo dot med.uc.edu @ 2014-11-13 21:00 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug middle-end/63793] -mcmodel=medium in gfortran on x86_64 emits references that are RIP relative (instead of using the GOT)
2014-11-09 14:17 [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
` (7 preceding siblings ...)
2014-11-13 21:00 ` howarth at bromo dot med.uc.edu
@ 2014-11-13 21:04 ` howarth at bromo dot med.uc.edu
2014-11-14 0:24 ` howarth at bromo dot med.uc.edu
` (6 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: howarth at bromo dot med.uc.edu @ 2014-11-13 21:04 UTC (permalink / raw)
To: gcc-bugs
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].
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug middle-end/63793] -mcmodel=medium in gfortran on x86_64 emits references that are RIP relative (instead of using the GOT)
2014-11-09 14:17 [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
` (8 preceding siblings ...)
2014-11-13 21:04 ` howarth at bromo dot med.uc.edu
@ 2014-11-14 0:24 ` howarth at bromo dot med.uc.edu
2014-11-14 0:33 ` iains at gcc dot gnu.org
` (5 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: howarth at bromo dot med.uc.edu @ 2014-11-14 0:24 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug middle-end/63793] -mcmodel=medium in gfortran on x86_64 emits references that are RIP relative (instead of using the GOT)
2014-11-09 14:17 [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
` (9 preceding siblings ...)
2014-11-14 0:24 ` howarth at bromo dot med.uc.edu
@ 2014-11-14 0:33 ` iains at gcc dot gnu.org
2014-11-14 0:38 ` howarth at bromo dot med.uc.edu
` (4 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: iains at gcc dot gnu.org @ 2014-11-14 0:33 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug middle-end/63793] -mcmodel=medium in gfortran on x86_64 emits references that are RIP relative (instead of using the GOT)
2014-11-09 14:17 [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
` (10 preceding siblings ...)
2014-11-14 0:33 ` iains at gcc dot gnu.org
@ 2014-11-14 0:38 ` howarth at bromo dot med.uc.edu
2014-11-14 0:55 ` howarth at bromo dot med.uc.edu
` (3 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: howarth at bromo dot med.uc.edu @ 2014-11-14 0:38 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug middle-end/63793] -mcmodel=medium in gfortran on x86_64 emits references that are RIP relative (instead of using the GOT)
2014-11-09 14:17 [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
` (11 preceding siblings ...)
2014-11-14 0:38 ` howarth at bromo dot med.uc.edu
@ 2014-11-14 0:55 ` howarth at bromo dot med.uc.edu
2014-11-14 0:59 ` howarth at bromo dot med.uc.edu
` (2 subsequent siblings)
15 siblings, 0 replies; 17+ messages in thread
From: howarth at bromo dot med.uc.edu @ 2014-11-14 0:55 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug middle-end/63793] -mcmodel=medium in gfortran on x86_64 emits references that are RIP relative (instead of using the GOT)
2014-11-09 14:17 [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
` (12 preceding siblings ...)
2014-11-14 0:55 ` howarth at bromo dot med.uc.edu
@ 2014-11-14 0:59 ` howarth at bromo dot med.uc.edu
2014-11-14 1:05 ` howarth at bromo dot med.uc.edu
2014-11-14 2:10 ` howarth at bromo dot med.uc.edu
15 siblings, 0 replies; 17+ messages in thread
From: howarth at bromo dot med.uc.edu @ 2014-11-14 0:59 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug middle-end/63793] -mcmodel=medium in gfortran on x86_64 emits references that are RIP relative (instead of using the GOT)
2014-11-09 14:17 [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
` (13 preceding siblings ...)
2014-11-14 0:59 ` howarth at bromo dot med.uc.edu
@ 2014-11-14 1:05 ` howarth at bromo dot med.uc.edu
2014-11-14 2:10 ` howarth at bromo dot med.uc.edu
15 siblings, 0 replies; 17+ messages in thread
From: howarth at bromo dot med.uc.edu @ 2014-11-14 1:05 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 17+ messages in thread* [Bug middle-end/63793] -mcmodel=medium in gfortran on x86_64 emits references that are RIP relative (instead of using the GOT)
2014-11-09 14:17 [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
` (14 preceding siblings ...)
2014-11-14 1:05 ` howarth at bromo dot med.uc.edu
@ 2014-11-14 2:10 ` howarth at bromo dot med.uc.edu
15 siblings, 0 replies; 17+ messages in thread
From: howarth at bromo dot med.uc.edu @ 2014-11-14 2:10 UTC (permalink / raw)
To: gcc-bugs
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;
}
^ permalink raw reply [flat|nested] 17+ messages in thread