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 optimization/13158] bad unwind info as a result of sibcall


------- Additional Comments From wilson at specifixinc dot com  2003-11-30 00:08 -------
Subject: Re:  New: bad unwind info as a result of sibcall

davidm at hpl dot hp dot com wrote:
> I have a distinct feeling of deja vue here, but I can't find any previous
> discussion around this, so maybe it was never reported.  Anyhow, the problem is
> that when GCC applies the sibcall optimization on ia64, it doesn't emit proper
> unwind info.  Example:

I believe this was reported in private mail to me, and maybe also 
Richard Henderson.

I started on a patch for this, but never finished it.  This was around 
the time I left Red Hat, so I think the main reason I didn't finish it 
was that I lost access to IA-64 hardware for a while.  This patch just 
emits a .prologue directive for the second alloc which is a start, but 
may not be enough.

Using .endp/.proc seems like a misuse of those directives.  Also, .proc 
requires a name, and the docs say that name must be defined as a label 
in between the .proc/.endp, so that may cause pollution of the label 
namespace to use them for non-functions.
Index: gcc/config/ia64/ia64.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/ia64/ia64.c,v
retrieving revision 1.201
diff -p -r1.201 ia64.c
*** gcc/config/ia64/ia64.c	20 Dec 2002 04:30:47 -0000	1.201
--- gcc/config/ia64/ia64.c	18 Feb 2003 18:51:53 -0000
*************** ia64_expand_epilogue (sibcall_p)
*** 2813,2822 ****
  	 preserve those input registers used as arguments to the sibling call.
  	 It is unclear how to compute that number here.  */
        if (current_frame_info.n_input_regs != 0)
! 	emit_insn (gen_alloc (gen_rtx_REG (DImode, fp),
! 			      GEN_INT (0), GEN_INT (0),
! 			      GEN_INT (current_frame_info.n_input_regs),
! 			      GEN_INT (0)));
      }
  }
  
--- 2813,2825 ----
  	 preserve those input registers used as arguments to the sibling call.
  	 It is unclear how to compute that number here.  */
        if (current_frame_info.n_input_regs != 0)
! 	{
! 	  insn = emit_insn (gen_alloc (gen_rtx_REG (DImode, fp),
! 				       GEN_INT (0), GEN_INT (0),
! 				       GEN_INT (current_frame_info.n_input_regs),
! 				       GEN_INT (0)));
! 	  RTX_FRAME_RELATED_P (insn) = 1;
! 	}
      }
  }
  
*************** process_set (asm_out_file, pat)
*** 7292,7304 ****
      {
        dest_regno = REGNO (dest);
  
!       /* If this isn't the final destination for ar.pfs, the alloc
! 	 shouldn't have been marked frame related.  */
!       if (dest_regno != current_frame_info.reg_save_ar_pfs)
! 	abort ();
  
-       fprintf (asm_out_file, "\t.save ar.pfs, r%d\n",
- 	       ia64_dbx_register_number (dest_regno));
        return 1;
      }
  
--- 7295,7311 ----
      {
        dest_regno = REGNO (dest);
  
!       /* If this is the final destination for ar.pfs, then this must be
! 	 the alloc in the prologue.  */
!       if (dest_regno == current_frame_info.reg_save_ar_pfs)
! 	fprintf (asm_out_file, "\t.save ar.pfs, r%d\n",
! 		 ia64_dbx_register_number (dest_regno));
! 
!       /* This must be an alloc before a sibcall.  We must start a new
! 	 prologue region here since we are modifying the frame info.  */
!       else
! 	fprintf (asm_out_file, "\t.prologue\n");
  
        return 1;
      }
  


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13158


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