[Bug debug/43290] ICE in dwarf2out_frame_debug_expr

[Bug debug/43290] ICE in dwarf2out_frame_debug_expr

[dirtyepic at gentoo dot org]

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

Ryan Hill <dirtyepic at gentoo dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dirtyepic at gentoo dot org

--- Comment #20 from Ryan Hill <dirtyepic at gentoo dot org> 2011-03-04 21:54:01 UTC ---
We're hitting this on vanilla 4.4.5.  Any chance of a backport?

https://bugs.gentoo.org/357287

[Bug debug/43290] ICE in dwarf2out_frame_debug_expr

[dirtyepic at gentoo dot org]

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

--- Comment #21 from Ryan Hill <dirtyepic at gentoo dot org> 2011-03-09 02:28:21 UTC ---
this is an in-branch regression from 4.4.4 and prevents -march=native bootstrap
on Sandy Bridge.  want a new bug?

[Bug debug/43290] ICE in dwarf2out_frame_debug_expr

[dirtyepic at gentoo dot org]

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

--- Comment #22 from Ryan Hill <dirtyepic at gentoo dot org> 2011-10-07 01:37:51 UTC ---
And now 4.4.6.

[Bug debug/43290] ICE in dwarf2out_frame_debug_expr

[jakub at gcc dot gnu dot org]

------- Comment #19 from jakub at gcc dot gnu dot org  2010-03-10 18:17 -------
Subject: Bug 43290

Author: jakub
Date: Wed Mar 10 18:17:10 2010
New Revision: 157363

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157363
Log:
        PR debug/43290
        * reg-notes.def (REG_CFA_SET_VDRAP): New note.
        * dwarf2out.c (dwarf2out_frame_debug_expr): Remove rule 20 - setting
        of fde->vdrap_reg.
        (dwarf2out_frame_debug): Handle REG_CFA_SET_VDRAP note.
        (based_loc_descr): Only express drap or vdrap regno based expressions
        using DW_OP_fbreg when not optimizing.
        * config/i386/i386.c (ix86_get_drap_rtx): When not optimizing,
        make the vDRAP = DRAP assignment RTX_FRAME_RELATED_P and add
        REG_CFA_SET_VDRAP note.

        PR debug/36728
        * gcc.dg/guality/pr36728-1.c: New test.
        * gcc.dg/guality/pr36728-2.c: New test.

Added:
    trunk/gcc/testsuite/gcc.dg/guality/pr36728-1.c
    trunk/gcc/testsuite/gcc.dg/guality/pr36728-2.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/i386/i386.c
    trunk/gcc/dwarf2out.c
    trunk/gcc/reg-notes.def
    trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug debug/43290] ICE in dwarf2out_frame_debug_expr

[jakub at gcc dot gnu dot org]

------- Comment #18 from jakub at gcc dot gnu dot org  2010-03-10 08:07 -------
Created an attachment (id=20073)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20073&action=view)
gcc45-pr43290.patch

Updated patch.  This one includes testcases, and also fixes for -O+, when
optimizing we really shouldn't be replacing random registers that once happened
to be vDRAP or DRAP somewhere with DW_OP_fbreg and there is no point tracking
it at all - after all when optimizing combiner or some other optimization pass
will very likely remove the vDRAP = DRAP insn anyway.  For -O1+ var-tracking is
supposed to do the right job finding where the variable lives.


-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #20072|0                           |1
        is obsolete|                            |


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

[Bug debug/43290] ICE in dwarf2out_frame_debug_expr

[hjl dot tools at gmail dot com]

------- Comment #17 from hjl dot tools at gmail dot com  2010-03-10 05:37 -------
(In reply to comment #15)
> Yes, sticking them in gcc/testsuite/gcc.dg/guality/ and using 
> /* { dg-final { gdb-test <line> "<varname>" "<expectedvalue>" } } */
> 
> If my patch really broke that, then I think we'll need to use some REG_CFA_*
> note or something similar to be able to differentiate between this vDRAP = DRAP
> insn and saving DRAP into a prologue save slot.
> 

I will add some testcases for PR 36728 to make sure that it isn't
broken.


-- 


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

[Bug debug/43290] ICE in dwarf2out_frame_debug_expr

[jakub at gcc dot gnu dot org]

------- Comment #16 from jakub at gcc dot gnu dot org  2010-03-10 00:33 -------
Created an attachment (id=20072)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20072&action=view)
gcc45-pr43290.patch

Untested patch.


-- 


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

[Bug debug/43290] ICE in dwarf2out_frame_debug_expr

[jakub at gcc dot gnu dot org]

------- Comment #15 from jakub at gcc dot gnu dot org  2010-03-09 22:54 -------
Yes, sticking them in gcc/testsuite/gcc.dg/guality/ and using 
/* { dg-final { gdb-test <line> "<varname>" "<expectedvalue>" } } */

If my patch really broke that, then I think we'll need to use some REG_CFA_*
note or something similar to be able to differentiate between this vDRAP = DRAP
insn and saving DRAP into a prologue save slot.


-- 


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

[Bug debug/43290] ICE in dwarf2out_frame_debug_expr

[hjl dot tools at gmail dot com]

------- Comment #14 from hjl dot tools at gmail dot com  2010-03-09 22:44 -------
Is there a way to add debug testcases from PR 36728 to gcc testsuite?


-- 


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

[Bug debug/43290] ICE in dwarf2out_frame_debug_expr

[hjl dot tools at gmail dot com]

------- Comment #13 from hjl dot tools at gmail dot com  2010-03-09 22:39 -------
(In reply to comment #9)
> (In reply to comment #8)
> > Created an attachment (id=20044)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20044&action=view) [edit]
> > gcc44-pr43290-2.patch
> > 
> > Another fix.  Wonder why that insn is marked as frame related at all, for the
> > drap saving the spill (and restore) generated by
> > ix86_expand_prologue/ix86_expand_epilogue should be the canonical one, after
> > all where the vDRAP was spilled to is something that could be clobbered before
> > the epilogue if vDRAP starts living in the register again, etc.
> > 
> 
> There may be a reason to do so at the time. If there are no
> regressions in gcc testsuite, it probably is OK not to mark
> drap as frame related.
> 

It is for PR 36728.


-- 


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

[Bug debug/43290] ICE in dwarf2out_frame_debug_expr

[jakub at gcc dot gnu dot org]

------- Comment #12 from jakub at gcc dot gnu dot org  2010-03-09 19:01 -------
Fixed for 4.5+.


-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |4.5.0


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

[Bug debug/43290] ICE in dwarf2out_frame_debug_expr

[jakub at gcc dot gnu dot org]

------- Comment #11 from jakub at gcc dot gnu dot org  2010-03-09 18:49 -------
Subject: Bug 43290

Author: jakub
Date: Tue Mar  9 18:48:43 2010
New Revision: 157313

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157313
Log:
        PR debug/43290
        * config/i386/i386.c (ix86_get_drap_rtx): Don't set
        RTX_FRAME_RELATED_P.

        * g++.dg/eh/unwind2.C: New test.

Added:
    trunk/gcc/testsuite/g++.dg/eh/unwind2.C
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/i386/i386.c
    trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug debug/43290] ICE in dwarf2out_frame_debug_expr

[jakub at gcc dot gnu dot org]

------- Comment #10 from jakub at gcc dot gnu dot org  2010-03-08 17:00 -------
I'll test it, both on the trunk and 4.4-RH.

BTW, I've moved the 2) issue to PR43293.


-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |jakub at gcc dot gnu dot org
                   |dot org                     |
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2010-03-08 17:00:56
               date|                            |


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

[Bug debug/43290] ICE in dwarf2out_frame_debug_expr

[hjl dot tools at gmail dot com]

------- Comment #9 from hjl dot tools at gmail dot com  2010-03-08 16:58 -------
(In reply to comment #8)
> Created an attachment (id=20044)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20044&action=view) [edit]
> gcc44-pr43290-2.patch
> 
> Another fix.  Wonder why that insn is marked as frame related at all, for the
> drap saving the spill (and restore) generated by
> ix86_expand_prologue/ix86_expand_epilogue should be the canonical one, after
> all where the vDRAP was spilled to is something that could be clobbered before
> the epilogue if vDRAP starts living in the register again, etc.
> 

There may be a reason to do so at the time. If there are no
regressions in gcc testsuite, it probably is OK not to mark
drap as frame related.


-- 


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

[Bug debug/43290] ICE in dwarf2out_frame_debug_expr

[jakub at gcc dot gnu dot org]

------- Comment #8 from jakub at gcc dot gnu dot org  2010-03-08 16:45 -------
Created an attachment (id=20044)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20044&action=view)
gcc44-pr43290-2.patch

Another fix.  Wonder why that insn is marked as frame related at all, for the
drap saving the spill (and restore) generated by
ix86_expand_prologue/ix86_expand_epilogue should be the canonical one, after
all where the vDRAP was spilled to is something that could be clobbered before
the epilogue if vDRAP starts living in the register again, etc.


-- 


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

[Bug debug/43290] ICE in dwarf2out_frame_debug_expr

[jakub at gcc dot gnu dot org]

------- Comment #7 from jakub at gcc dot gnu dot org  2010-03-08 16:39 -------
Created an attachment (id=20043)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20043&action=view)
gcc44-pr43290-1.patch

One alternative fix that cures this testcase on redhat/gcc-4_4-branch.


-- 


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

[Bug debug/43290] ICE in dwarf2out_frame_debug_expr

[jakub at gcc dot gnu dot org]

------- Comment #6 from jakub at gcc dot gnu dot org  2010-03-08 16:38 -------
Not sure if there haven't been follow-ups.  There were at least 100 changes to
dwarf2out.c since 4.4 release, and at least 10 of them were related to the
indirect vs. direct stuff.


-- 


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

[Bug debug/43290] ICE in dwarf2out_frame_debug_expr

[hjl dot tools at gmail dot com]

------- Comment #5 from hjl dot tools at gmail dot com  2010-03-08 15:47 -------
(In reply to comment #4)
> Ah, the %ebp saved in DW_OP_reg5 is just a 4.4 bug, fixed by
> http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00235.html (the fix is in 4.5 and
> 4.4-RH).  Saying that %ebp is saved in DW_OP_breg5 0 is correct and desirable.
> 

Can we backport it to 4.4?


-- 


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

[Bug debug/43290] ICE in dwarf2out_frame_debug_expr

[jakub at gcc dot gnu dot org]

------- Comment #4 from jakub at gcc dot gnu dot org  2010-03-08 15:44 -------
Ah, the %ebp saved in DW_OP_reg5 is just a 4.4 bug, fixed by
http://gcc.gnu.org/ml/gcc-patches/2009-05/msg00235.html (the fix is in 4.5 and
4.4-RH).  Saying that %ebp is saved in DW_OP_breg5 0 is correct and desirable.


-- 


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

[Bug debug/43290] ICE in dwarf2out_frame_debug_expr

[hjl dot tools at gmail dot com]

------- Comment #3 from hjl dot tools at gmail dot com  2010-03-08 15:27 -------
(In reply to comment #2)
> I've tried, but haven't succeeded, that's why I said the bug is latent there. 
> If we can prove this situation can't ever happen on 4.4 or 4.5 (4.5 on this
> testcase doesn't use a drap reg at all, so we'd need some other testcase where
> it does), then I'll of course do something on our branch only.  But I believe
> this is just a general problem.  BTW, even the 4.4 generated unwind info is
> bad:

Can you make a run-time testcase out of it?


-- 


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

[Bug debug/43290] ICE in dwarf2out_frame_debug_expr

[jakub at gcc dot gnu dot org]

------- Comment #2 from jakub at gcc dot gnu dot org  2010-03-08 15:12 -------
I've tried, but haven't succeeded, that's why I said the bug is latent there. 
If we can prove this situation can't ever happen on 4.4 or 4.5 (4.5 on this
testcase doesn't use a drap reg at all, so we'd need some other testcase where
it does), then I'll of course do something on our branch only.  But I believe
this is just a general problem.  BTW, even the 4.4 generated unwind info is
bad:
  DW_CFA_advance_loc: 4 to 00000004
  DW_CFA_def_cfa: r1 (ecx) ofs 0
  DW_CFA_advance_loc: 9 to 0000000d
  DW_CFA_expression: r5 (ebp) (DW_OP_reg5)
  DW_CFA_advance_loc: 11 to 00000018
  DW_CFA_def_cfa_expression (DW_OP_breg5: -16; DW_OP_deref)
  DW_CFA_advance_loc: 20 to 0000002c
  DW_CFA_expression: r7 (edi) (DW_OP_breg5: -4)
  DW_CFA_expression: r6 (esi) (DW_OP_breg5: -8)
  DW_CFA_expression: r3 (ebx) (DW_OP_breg5: -12)

   0:   8d 4c 24 04             lea    0x4(%esp),%ecx
   4:   83 e4 e0                and    $0xffffffe0,%esp
   7:   ff 71 fc                pushl  -0x4(%ecx)
   a:   55                      push   %ebp
   b:   89 e5                   mov    %esp,%ebp
   d:   83 ec 78                sub    $0x78,%esp
  10:   89 5c 24 6c             mov    %ebx,0x6c(%esp)
  14:   89 4c 24 68             mov    %ecx,0x68(%esp)
  18:   89 74 24 70             mov    %esi,0x70(%esp)
  1c:   89 7c 24 74             mov    %edi,0x74(%esp)
  20:   e8 00 00 00 00          call   25
<_ZNSt13basic_filebufIcSt11char_traitsIcEE7seekposESt4fposI9mbstate_tEN12_GLOBAL__N_113_Ios_OpenmodeE+0x25>
  25:   5b                      pop    %ebx
  26:   81 c3 03 00 00 00       add    $0x3,%ebx
                        28: R_386_GOTPC _GLOBAL_OFFSET_TABLE_
  2c:   8b 31                   mov    (%ecx),%esi
  2e:   89 4d c4                mov    %ecx,-0x3c(%ebp)
1) Saying that %r5 (ebp) is saved in DW_OP_reg5 looks quite redundant to me.
2) More importantly, %ebx is said to be saved in DW_OP_breg5 - 12 only after
add $0x3, %ebx, so when e.g. a debugger stops in between pop %ebx and add $3,
%ebx, it will think caller's %ebx still lives in %ebx register, which is wrong.


-- 


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

[Bug debug/43290] ICE in dwarf2out_frame_debug_expr

[hjl dot tools at gmail dot com]

------- Comment #1 from hjl dot tools at gmail dot com  2010-03-08 15:03 -------
Can you make it to fail on trunk or 4.4 branch since it
could be caused by other changes on redhat/gcc-4_4-branch?
If not, can you find out which change on redhat/gcc-4_4-branch
causes this?


-- 


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