I have a user who is trying to use the large code model on x86-64 Linux
(-mcmodel=large) and is running into some trouble and I have a couple of
questions for the x86-64 experts/maintainers.
The first one is: would it be reasonable to compile crt files with
-mcmodel=large by default on the x86-64 linux platform? Currently the
crt files are not compiled with this option and that makes it impossible
to compile a program where the text segment is above 4GB (for example)
because the crt files can't handle the large code model if they aren't
compiled with this option.
The second issue is a couple of bugs we have run into while trying to
compile crtstuff.c with this option. The first bug is in
cselib_hash_rtx where it can't handle the 'u' and 'B' format codes in an
rtx. I fixed this by skipping them just like '0' and 't' are skipped
but that resulted in the second bug:
x.c:15: error: invalid rtl sharing found in the insn
(insn 84 83 85 2 x.c:5 (set (reg:DI 40 r11)
(unspec:DI [
(note/s 82 81 83 2 "" NOTE_INSN_DELETED_LABEL 6)
] 17)) -1 (nil))
x.c:15: error: shared rtx
(note/s 82 81 83 2 "" NOTE_INSN_DELETED_LABEL 6)
x.c:15: internal compiler error: internal consistency failure
Both issues can be reproduced by compiling this code from crtstuff.c
on an x86-64 linux box with '-O2 -fPIC -mcmodel=large'.
typedef long unsigned int size_t;
typedef void (*func_ptr) (void);
static func_ptr __DTOR_LIST__[1] = { (func_ptr) (-1) };
static void __attribute__((used)) __do_global_dtors_aux (void)
{
extern func_ptr __DTOR_END__[];
size_t dtor_idx = 0;
const size_t max_idx = __DTOR_END__ - __DTOR_LIST__ - 1;
func_ptr f;
while (dtor_idx < max_idx)
{
f = __DTOR_LIST__[++dtor_idx];
f ();
}
}
I think the second bug is coming from the label created in
ix86_expand_prologue (line 8154) when generating the set_rip_rex64 and
set_got_offset_rex64 instructions and that later gets removed during
optimization but I am not sure what to do about it.
Steve Ellcey
s...@cup.hp.com
