[Bug c/13158] New: bad unwind info as a result of sibcall

[Bug c/13158] New: bad unwind info as a result of sibcall

[davidm at hpl dot hp dot com]

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:

$ cat bug.c
extern int foo (int);

int main (int argc, char **argv) {
  printf ("hello\n");
  return foo (argc);
}

int foo (int arg) {
  return 0;
}
$ gcc -v
Reading specs from /opt/gcc-pre3.4/lib/gcc/ia64-hp-linux/3.4/specs
Configured with:  : (reconfigured)  : (reconfigured)  : (reconfigured)  :
(reconfigured) 
Thread model: posix
gcc version 3.4 20031121 (experimental)
$ gcc -O2 -c bug.c
$ readelf -u bug.o

Unwind section '.IA_64.unwind' at offset 0xd0 contains 1 entries:

<main>: [0x10-0x70], info at +0x0
  v1, flags=0x0 (), len=8 bytes
    R2:prologue_gr(mask=[rp,ar.pfs],grsave=r33,rlen=5)
        P7:pfs_when(t=0)
        P7:rp_when(t=2)
    R1:body(rlen=13)
$ objdump -d bug.o | tail -19
0000000000000010 <main>:
  10:   0c 10 15 08 80 05       [MFI]       alloc r34=ar.pfs,5,4,0
  16:   00 00 00 02 00 20                   nop.f 0x0
  1c:   04 00 c4 00                         mov r33=b0
  20:   02 20 01 02 00 24       [MII]       addl r36=0,r1
  26:   30 02 04 00 42 00                   mov r35=r1;;
  2c:   00 00 04 00                         nop.i 0x0
  30:   1d 20 01 48 18 10       [MFB]       ld8 r36=[r36]
  36:   00 00 00 02 00 00                   nop.f 0x0
  3c:   08 00 00 50                         br.call.sptk.many b0=30;;
  40:   01 08 00 46 00 21       [MII]       mov r1=r35
  46:   00 08 05 80 03 00                   mov b0=r33
  4c:   20 02 aa 00                         mov.i ar.pfs=r34;;
  50:   1d 10 04 00 80 05       [MFB]       alloc r2=ar.pfs,1,0,0
  56:   00 00 00 02 00 00                   nop.f 0x0
  5c:   08 00 00 40                         br.many 50 <main+0x40>;;
  60:   1d 00 00 00 01 00       [MFB]       nop.m 0x0
  66:   00 00 00 00 00 00                   break.f 0x0
  6c:   00 00 00 20                         nop.b 0x0;;

The problem here is that the unwind info claims that even for the last six
instructions, ar.pfs is saved in r34 and rp in r33.  But after the "alloc"
instruction, those registers are not really valid anymore.  In particular, if
execution gets interrupted anywhere in the last six instructions, the contents
of those no-longer-allocated registers may get clobbered and at that point
unwinding may no longer be possible.

The best fix that I can think of would be to emit

       .restore sp

right before the instruction that restores ar.pfs (i.e., before the 7th-last 
instruction).  That would tell the unwinder that for the last six instructions,
rp and ar.pfs can be found in the default location (and nothing else has been
saved).  Of course, if a function has a memory stack frame, then the .restore sp
will be generated naturally for the instruction that restores the sp, so no such
dummy ".restore sp" directive would be needed.

-- 
           Summary: bad unwind info as a result of sibcall
           Product: gcc
           Version: 3.4
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: davidm at hpl dot hp dot com
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: ia64-hp-linux
  GCC host triplet: ia64-hp-linux
GCC target triplet: ia64-hp-linux


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

[Bug c/13158] bad unwind info as a result of sibcall

[davidm at hpl dot hp dot com]

------- Additional Comments From davidm at hpl dot hp dot com  2003-11-22 02:54 -------
Oops, there was a typo in my report: instead of 'after the "alloc"' it should
have said 'after the second "alloc"'.  Sorry.

-- 


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

[Bug c/13158] bad unwind info as a result of sibcall

[davidm at hpl dot hp dot com]

------- Additional Comments From davidm at hpl dot hp dot com  2003-11-22 04:51 -------
Sorry to keep adding to this but on the way home, I realized that .restore sp
won't fix the problem.  Instead, perhaps the best way to fix this would be to emit:

   .endp
   .proc

right before the second "alloc".  The only alternative I can think of would be
to use copy_state/label_state but that would get rather ugly and would cause
additional unwind directives that aren't really needed.

-- 


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

[Bug target/13158] bad unwind info as a result of sibcall

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c                           |target


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

[Bug optimization/13158] bad unwind info as a result of sibcall

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|target                      |optimization


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

[Bug optimization/13158] bad unwind info as a result of sibcall

[wilson at specifixinc dot com]

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

[Bug optimization/13158] bad unwind info as a result of sibcall

[wilson at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2003-11-30 00:10:46
               date|                            |


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

[Bug target/13158] bad unwind info as a result of sibcall

[davidm at hpl dot hp dot com]

------- Additional Comments From davidm at hpl dot hp dot com  2004-05-13 04:25 -------
(In reply to comment #3)
> This patch just 
> emits a .prologue directive for the second alloc which is a start, but 
> may not be enough.

It seems like a very good start, actually.

> Using .endp/.proc seems like a misuse of those directives.

Yes.  Thinking some more about it, perhaps the best way to handle it is to
ensure that there is a ".restore sp" directive and then issue a .prologue
right before the sibcall "alloc".  Assuming (a) unwind info at the point of a
sibcall is never nested (I believe that's true) and (b) that a sibcall cannot
occur within the normal prologue of the procedure (this better be true), then
this solution should be safe.  I attached a patch which consists simply of your
original patch plus the extra bit of code to generate ".restore sp" if we're
dealing with a procedure that doesn't have a memory-stack frame.

I tested the patch with the above "bug.c" routine when run under libunwind's
"test-ptrace" program (which single-steps through the program, unwinding the
stack at each point).  This test-case now succeeds, so the basics look good.



-- 


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

[Bug target/13158] bad unwind info as a result of sibcall

[wilson at specifixinc dot com]

------- Additional Comments From wilson at specifixinc dot com  2004-05-14 08:40 -------
Subject: Re:  bad unwind info as a result of sibcall

On Wed, 2004-05-12 at 21:25, davidm at hpl dot hp dot com wrote:
> I tested the patch with the above "bug.c" routine when run under libunwind's
> "test-ptrace" program (which single-steps through the program, unwinding the
> stack at each point).  This test-case now succeeds, so the basics look good.

This seems reasonable to me.  I tried testing the patch, and ended up
with 2 extra libjava failures.  I tried rerunning the libjava
testsuites, and the extra failures were repeatable.  I think I need to
look at this.  I am not exactly sure what the libjava testsuite was
trying to do.  It byte compiled a file to get a class file, and then
executed it?  I need to figure out more about what the libjava testsuite
was doing before I can look into this.


-- 


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

[Bug target/13158] bad unwind info as a result of sibcall

[davidm at hpl dot hp dot com]

------- Additional Comments From davidm at hpl dot hp dot com  2004-10-22 16:25 -------
(In reply to comment #6)
> Subject: Re:  bad unwind info as a result of sibcall
> 
> I tried testing the patch, and ended up with 2 extra libjava failures.

I was able to reproduce the libjava failures.  The problem was that the patch
didn't do the full epilogue processing for the sibcall.  With the
"revised-patch" applied, I get no additional failures anymore.  However, due to
a gas bug it produces epilogue directives with "t" value of -1 which isn't good
(though it doesn't hurt the existing ia64 linux unwinders).  I'll submit a patch
for gas to fix this problem.

If there are no other issues, could this patch be checked in?


-- 


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

[Bug target/13158] bad unwind info as a result of sibcall

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-10-27 22:44 -------
Subject: Bug 13158

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	wilson@gcc.gnu.org	2004-10-27 22:44:09

Modified files:
	gcc            : ChangeLog 
	gcc/config/ia64: ia64.c 

Log message:
	IA-64 sibcall unwind bug, PR target/13158
	* config/ia64/ia64.c (ia64_expand_epilogue): Set RTX_FRAME_RELATED_P on
	sibcall alloc instruction.
	(process_set): Handle sibcall alloc instruction.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.6057&r2=2.6058
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/ia64/ia64.c.diff?cvsroot=gcc&r1=1.328&r2=1.329



-- 


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

[Bug target/13158] bad unwind info as a result of sibcall

[wilson at gcc dot gnu dot org]

------- Additional Comments From wilson at gcc dot gnu dot org  2004-10-27 23:16 -------
Thanks for the help.  I got bogged down trying to figure out how to debug
gcj/libjava problems, and wasn't able to make any useful progress before getting
distracted by other stuff.

I've now checked the patch into mainline.

Adding the patch to gcc-3.4 requires that it be a regression.   This doesn't
seem to qualify according to a strict interpretation of the rules.  The same
broken code is in gcc-3.0.4, and gcc-2.96 doesn't really count, as there was no
official FSF gcc release including the IA-64 support before gcc-3.x.

-- 


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

[Bug target/13158] bad unwind info as a result of sibcall

[davidm at hpl dot hp dot com]

------- Additional Comments From davidm at hpl dot hp dot com  2004-10-28 09:27 -------
(In reply to comment #10)
> I've now checked the patch into mainline.

Thanks!

> Adding the patch to gcc-3.4 requires that it be a regression.   This doesn't
> seem to qualify according to a strict interpretation of the rules.

I'm not in tune with GCC release management so you/the release-manager will have
to make the call.  However, if we can't put the unwind fix(es) into 3.4, it will
mean we have to ask each distributor to pick them up separately.  This is a lot
of work for something that is (a) guaranteed to be ia64-specific (i.e., the
patches won't affect any other platforms) and (b) is known to cause real
problems.  Just my 2 cents...


-- 


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

[Bug target/13158] bad unwind info as a result of sibcall

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-11-24 22:23 -------
Subject: Bug 13158

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-3_4-rhl-branch
Changes by:	jakub@gcc.gnu.org	2004-11-24 22:22:29

Modified files:
	gcc            : ChangeLog emit-rtl.c 
	gcc/config/ia64: ia64.c 

Log message:
	2004-10-27  David Mosberger  <davidm@hpl.hp.com>
	James E Wilson  <wilson@specifixinc.com>
	
	PR target/13158
	* config/ia64/ia64.c (ia64_expand_epilogue): Set RTX_FRAME_RELATED_P on
	sibcall alloc instruction.
	(process_set): Handle sibcall alloc instruction.
	
	2004-10-26  James E Wilson  <wilson@specifixinc.com>
	
	PR target/18010
	* emit-rtl.c (emit_copy_of_insn_after): Copy RTX_FRAME_RELATED_P.
	
	2004-02-03  Kazu Hirata  <kazu@cs.umass.edu>
	
	* config/ia64/ia64.c: Use const0_rtx instead of GEN_INT (0).

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=2.2326.2.399.2.57&r2=2.2326.2.399.2.58
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/emit-rtl.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=1.365.4.5&r2=1.365.4.5.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/ia64/ia64.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-rhl-branch&r1=1.265.2.6.2.5&r2=1.265.2.6.2.6



-- 


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

[Bug target/13158] bad unwind info as a result of sibcall

[steven at gcc dot gnu dot org]

------- Additional Comments From steven at gcc dot gnu dot org  2004-12-18 13:30 -------
...so I can reopen it. 

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2004-08-14 07:05:01         |2004-12-18 13:30:15
               date|                            |


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

[Bug target/13158] bad unwind info as a result of sibcall

[steven at gcc dot gnu dot org]

------- Additional Comments From steven at gcc dot gnu dot org  2004-12-18 13:29 -------
The patch to fix this introduces another wrong-code bug, PR18987. 
I have not checked if this bug is also present on the GCC 3.4 branch now. 
 
Suspending... 
 
 

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |SUSPENDED


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

[Bug target/13158] bad unwind info as a result of sibcall

[steven at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|SUSPENDED                   |NEW
   Last reconfirmed|2004-12-18 13:30:15         |2004-12-18 13:31:27
               date|                            |


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

[Bug target/13158] [ia64] bad unwind info as a result of sibcall

[steven at gcc dot gnu dot org]

------- Additional Comments From steven at gcc dot gnu dot org  2004-12-18 13:32 -------
This is a target bug of course.  Mark it as such. 
 

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|bad unwind info as a result |[ia64] bad unwind info as a
                   |of sibcall                  |result of sibcall


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

[Bug target/13158] [ia64] bad unwind info as a result of sibcall

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-01-13 05:57 -------
Subject: Bug 13158

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-3_4-branch
Changes by:	wilson@gcc.gnu.org	2005-01-13 05:57:06

Modified files:
	gcc            : ChangeLog 
	gcc/config/ia64: ia64.c 

Log message:
	Patches to fix sibcall unwind info problems.
	PR target/18987
	* config/ia64/ia64.c (process_set): For alloc insn, only call
	process_epilogue is !frame_pointer_needed.
	PR target/13158
	* config/ia64/ia64.c (ia64_expand_epilogue): Set RTX_FRAME_RELATED_P on
	sibcall alloc instruction.
	(process_set): Handle sibcall alloc instruction.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=2.2326.2.767&r2=2.2326.2.768
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/ia64/ia64.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.265.2.16&r2=1.265.2.17



-- 


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

[Bug target/13158] [ia64] bad unwind info as a result of sibcall

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-01-14 19:15 -------
Subject: Bug 13158

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-3_3-branch
Changes by:	wilson@gcc.gnu.org	2005-01-14 19:15:41

Modified files:
	gcc            : ChangeLog 
	gcc/config/ia64: ia64.c 

Log message:
	Patches to fix sibcall unwind info bugs.
	PR target/18987
	* config/ia64/ia64.c (process_set): For alloc insn, only call
	process_epilogue is !frame_pointer_needed.
	PR target/13158
	* config/ia64/ia64.c (ia64_expand_epilogue): Set RTX_FRAME_RELATED_P on
	sibcall alloc instruction.
	(process_set): Handle sibcall alloc instruction.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.16114.2.1051&r2=1.16114.2.1052
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/ia64/ia64.c.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.198.2.23&r2=1.198.2.24



-- 


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

[Bug target/13158] [ia64] bad unwind info as a result of sibcall

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2005-01-14 19:45 -------
Subject: Bug 13158

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	wilson@gcc.gnu.org	2005-01-14 19:45:23

Modified files:
	gcc/testsuite  : ChangeLog 
Added files:
	gcc/testsuite/gcc.target/ia64: ia64.exp sibcall-unwind-1.c 
	                               sibcall-unwind-2.c 

Log message:
	Testcases for sibcall unwind info problems.
	PR target/13158
	* gcc.target/ia64/sibcall-unwind-1.c: New test.
	PR target/18987
	* gcc.target/ia64/sibcall-unwind-2.c: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.4885&r2=1.4886
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.target/ia64/ia64.exp.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.target/ia64/sibcall-unwind-1.c.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.target/ia64/sibcall-unwind-2.c.diff?cvsroot=gcc&r1=NONE&r2=1.1



-- 


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

[Bug target/13158] [ia64] bad unwind info as a result of sibcall

[wilson at gcc dot gnu dot org]

------- Additional Comments From wilson at gcc dot gnu dot org  2005-01-14 19:51 -------
Fixed on mainline, gcc-3.4, and gcc-3.3.  Testcase added to mainline.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


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

[Bug target/13158] [ia64] bad unwind info as a result of sibcall

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |3.3.6


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