This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]