This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
ppc glibc 2.3 failure
- From: Aldy Hernandez <aldyh at redhat dot com>
- To: dalej at apple dot com, dje at watson dot ibm dot com, gcc at gcc dot gnu dot org
- Date: Mon, 7 Oct 2002 16:06:03 -0700
- Subject: ppc glibc 2.3 failure
Hi guys.
The following distilled case from glibc from CVS...
char *banner;
extern int __write (char *) __attribute__ ((visibility ("hidden")));
void foo() { __write (banner); }
...fails to compile with -O2 -fpic on linuxppc:
a.c:4: error: Attempt to delete prologue/epilogue insn:
(insn 32 31 33 0 (nil) (set (reg:SI 65 lr)
(reg:SI 11 r11)) -1 (nil)
(nil))
I haven't done *deep* debugging, but the problem goes away if I remove
Dale's patch below.
Here is what happens: at prologue time, we set LR here (because
info_ptr->lr_save_p is false, etc):
if (save_LR_around_toc_setup)
emit_move_insn (gen_rtx_REG (Pmode, LINK_REGISTER_REGNUM),
gen_rtx_REG (Pmode, 11));
sometime between prologue generation and epilogue generation we call
rs6000_stack_info(), and end up setting info_ptr->lr_save_p to true,
which will cause us to generate this in the epilogue:
/* Set LR here to try to overlap restores below. */
if (info->lr_save_p)
emit_move_insn (gen_rtx_REG (Pmode, LINK_REGISTER_REGNUM),
gen_rtx_REG (Pmode, 0));
So what we have is rs6000_stack_info behaving different in subsequent
runs, and I've traced it to rs6000_ra_ever_killed() giving different
results. This will have us generating:
(set (reg lr) blah)
stuff
(set (reg lr) blah)
The first set (in the prologue) is dead, and flow will try to delete
it.
Dale, could you take a look at this?
2002-08-09 Dale Johannesen <dalej@apple.com>
* config/rs6000/rs6000.md: Add sibcall patterns.
* config/rs6000/rs6000.h (FUNCTION_OK_FOR_SIBCALL): Define.
* config/rs6000/rs6000.c (rs6000_ra_ever_killed):
Rewritten to handle sibcalls.
* config/rs6000/rs6000.c (function_ok_for_sibcall): New.
* config/rs6000/rs6000-protos.h (function_ok_for_sibcall): New.