[RFC/CFT] Hookize TARGET_UNWIND_INFO and related macros

On 09/17/2010 11:02 AM, Steve Ellcey wrote:
> Richard,
> 
> I finally has some time to test this patch on IA64 HP-UX and Linux and I
> got build failures on both systems.  Using a preprocessed version of
> libgcov.c I see:
> 
>  $ obj_gcc/gcc/cc1 -mlp64 -O2 -g -quiet x.i
> x.i: In function 'gcov_exit':
> x.i:3169:1: internal compiler error: in dwarf2out_frame_debug_expr, at
> dwarf2out.c:2304
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <http://gcc.gnu.org/bugs.html> for instructions.
> 
> Looks like it is failing on this assert:
> 
>              /* Saving a register in a register.  */
>               gcc_assert (!fixed_regs [REGNO (dest)]
>                           /* For the SPARC and its register window.  */
>                           || (DWARF_FRAME_REGNUM (REGNO (src))
>                               == DWARF_FRAME_RETURN_COLUMN));
> 
> It looks like both src and dest are:
> 
> (reg/f:DI 12 r12)
> 
> and r12 is listed in FIXED_REGISTERS as the stack pointer.

Try this.


r~

On Fri, 2010-09-17 at 20:45 -0700, Richard Henderson wrote:

> Try this.
> 
> 
> r~
> 
> 
> --- a/gcc/config/ia64/ia64.c
> +++ b/gcc/config/ia64/ia64.c
> @@ -3688,7 +3688,8 @@ ia64_expand_epilogue (int sibcall_p)
>    else if (frame_pointer_needed)
>      {
>        insn = emit_move_insn (stack_pointer_rtx, hard_frame_pointer_rtx);
> -      RTX_FRAME_RELATED_P (insn) = 1;
> +      /* We don't need to mark this frame-related, since the frame pointer
> +        will remain valid up until the return insn deallocates it.  */
>      }
>    else if (current_frame_info.total_size)
>      {

This gave me a different assert.

/proj/opensrc/nightly/src/trunk/libgcc/../gcc/libgcov.c: In function
'gcov_exit':
/proj/opensrc/nightly/src/trunk/libgcc/../gcc/libgcov.c:528:1: internal
compiler error: in dwarf2out_frame_debug_expr, at dwarf2out.c:2558

It looks like cfa_temp.reg is -1 and regno is 111 when the assert fails.

Steve Ellcey
sje@cup.hp.com

On 09/20/2010 09:27 AM, Steve Ellcey wrote:
> This gave me a different assert.
> 
> /proj/opensrc/nightly/src/trunk/libgcc/../gcc/libgcov.c: In function
> 'gcov_exit':
> /proj/opensrc/nightly/src/trunk/libgcc/../gcc/libgcov.c:528:1: internal
> compiler error: in dwarf2out_frame_debug_expr, at dwarf2out.c:2558
> 
> It looks like cfa_temp.reg is -1 and regno is 111 when the assert fails.

How about removing the other RTX_FRAME_RELATED_P from the 
epilogue also.  The one just below attached to the alloc
just before the sibcall.

I had removed both in testing here, but thought after the
fact that just the first would be sufficient.


r~

On Mon, 2010-09-20 at 10:05 -0700, Richard Henderson wrote:
> On 09/20/2010 09:27 AM, Steve Ellcey wrote:
> > This gave me a different assert.
> > 
> > /proj/opensrc/nightly/src/trunk/libgcc/../gcc/libgcov.c: In function
> > 'gcov_exit':
> > /proj/opensrc/nightly/src/trunk/libgcc/../gcc/libgcov.c:528:1: internal
> > compiler error: in dwarf2out_frame_debug_expr, at dwarf2out.c:2558
> > 
> > It looks like cfa_temp.reg is -1 and regno is 111 when the assert fails.
> 
> How about removing the other RTX_FRAME_RELATED_P from the 
> epilogue also.  The one just below attached to the alloc
> just before the sibcall.
> 
> I had removed both in testing here, but thought after the
> fact that just the first would be sufficient.
> 
> 
> r~

There are still two RTX_FRAME_RELATED_P uses in ia64.c, and I was not
sure which one you meant but getting rid of either (or both of them)
didn't help.  I got the same assert.  This is on HP-UX, compiling
libgcov in 32 bit mode.  It looks like it does compile in 64 bit mode
with this change.

Steve Ellcey
sje@cup.hp.com

On 09/20/2010 10:23 AM, Steve Ellcey wrote:
> There are still two RTX_FRAME_RELATED_P uses in ia64.c, and I was not
> sure which one you meant but getting rid of either (or both of them)
> didn't help.  I got the same assert.  This is on HP-UX, compiling
> libgcov in 32 bit mode.  It looks like it does compile in 64 bit mode
> with this change.

Ah, right.  I'll have another look at hpux specifically.


r~