public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug debug/37982]  New: Extranious DW_TAG_variable tag
@ 2008-10-31 19:05 swagiaal at redhat dot com
  2008-10-31 19:07 ` [Bug debug/37982] " swagiaal at redhat dot com
                   ` (10 more replies)
  0 siblings, 11 replies; 12+ messages in thread
From: swagiaal at redhat dot com @ 2008-10-31 19:05 UTC (permalink / raw)
  To: gcc-bugs

The attached test case compiled thus: g++ -g class.c class2.c -o class

produces the following debuginfo:

 <0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
    < c>   DW_AT_producer    : (indirect string, offset: 0x36): GNU C++ 4.3.0
20080428 (Red Hat 4.3.0-8)        
    <10>   DW_AT_language    : 4        (C++)
    <11>   DW_AT_name        : (indirect string, offset: 0x0): class.c  
    <15>   DW_AT_comp_dir    : (indirect string, offset: 0x19):
/notnfs/swagiaal/tests/class    
    <19>   DW_AT_low_pc      : 0x40055c 
    <21>   DW_AT_high_pc     : 0x400568 
    <29>   DW_AT_stmt_list   : 0x0      
 <1><2d>: Abbrev Number: 2 (DW_TAG_class_type)
    <2e>   DW_AT_name        : A        
    <30>   DW_AT_byte_size   : 1        
    <31>   DW_AT_decl_file   : 2        
    <32>   DW_AT_decl_line   : 4        
    <33>   DW_AT_sibling     : <0x49>   
 <2><37>: Abbrev Number: 3 (DW_TAG_variable)
    <38>   DW_AT_name        : (indirect string, offset: 0x5f): elsewhere       
    <3c>   DW_AT_decl_file   : 2        
    <3d>   DW_AT_decl_line   : 6        
    <3e>   DW_AT_MIPS_linkage_name: (indirect string, offset: 0x8):
_ZN1A9elsewhereE    
    <42>   DW_AT_type        : <0x49>   
    <46>   DW_AT_external    : 1        
    <47>   DW_AT_declaration : 1        
[...]
 <1><86>: Abbrev Number: 3 (DW_TAG_variable)
    <87>   DW_AT_name        : (indirect string, offset: 0x5f): elsewhere       
    <8b>   DW_AT_decl_file   : 2        
    <8c>   DW_AT_decl_line   : 6        
    <8d>   DW_AT_MIPS_linkage_name: (indirect string, offset: 0x8):
_ZN1A9elsewhereE    
    <91>   DW_AT_type        : <0x49>   
    <95>   DW_AT_external    : 1        
    <96>   DW_AT_declaration : 1        

[...]


 <0><a3>: Abbrev Number: 1 (DW_TAG_compile_unit)
    <a4>   DW_AT_producer    : (indirect string, offset: 0x36): GNU C++ 4.3.0
20080428 (Red Hat 4.3.0-8)        
    <a8>   DW_AT_language    : 4        (C++)
    <a9>   DW_AT_name        : (indirect string, offset: 0x6e): class2.c        
    <ad>   DW_AT_comp_dir    : (indirect string, offset: 0x19):
/notnfs/swagiaal/tests/class    
    <b1>   DW_AT_low_pc      : 0x400568 
    <b9>   DW_AT_high_pc     : 0x400568 
    <c1>   DW_AT_stmt_list   : 0x46     
 <1><c5>: Abbrev Number: 2 (DW_TAG_class_type)
    <c6>   DW_AT_name        : A        
    <c8>   DW_AT_byte_size   : 1        
    <c9>   DW_AT_decl_file   : 1        
    <ca>   DW_AT_decl_line   : 4        
    <cb>   DW_AT_sibling     : <0xe1>   
 <2><cf>: Abbrev Number: 3 (DW_TAG_variable)
    <d0>   DW_AT_name        : (indirect string, offset: 0x5f): elsewhere       
    <d4>   DW_AT_decl_file   : 1        
    <d5>   DW_AT_decl_line   : 6        
    <d6>   DW_AT_MIPS_linkage_name: (indirect string, offset: 0x8):
_ZN1A9elsewhereE    
    <da>   DW_AT_type        : <0xe1>   
    <de>   DW_AT_external    : 1        
    <df>   DW_AT_declaration : 1        
[...]
 <1><ed>: Abbrev Number: 6 (DW_TAG_variable)
    <ee>   DW_AT_specification: <0xcf>  
    <f2>   DW_AT_decl_file   : 2        
    <f3>   DW_AT_decl_line   : 4        
    <f4>   DW_AT_location    : 9 byte block: 3 68 6 40 0 0 0 0 0       
(DW_OP_addr: 400668)
[...]
 The File Name Table:
  Entry Dir     Time    Size    Name
  1     0       0       0       class.c
  2     0       0       0       class.h
[...]
 The File Name Table:
  Entry Dir     Time    Size    Name
  1     0       0       0       class.h
  2     0       0       0       class2.c

As can be seen from the debug info there is an extra die (0x86).
This die is misleading to the debugger. In that compile unit there
are two die's representing declarations of the variable 'elsewhere'
0x37 and 0x86. The second one is in the incorrect scope and has no
reference to the correct die.

Please advise.

Thanks


-- 
           Summary: Extranious DW_TAG_variable tag
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: debug
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: swagiaal at redhat dot com


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


^ permalink raw reply	[flat|nested] 12+ messages in thread

* [Bug debug/37982] Extranious DW_TAG_variable tag
  2008-10-31 19:05 [Bug debug/37982] New: Extranious DW_TAG_variable tag swagiaal at redhat dot com
@ 2008-10-31 19:07 ` swagiaal at redhat dot com
  2008-10-31 19:08 ` swagiaal at redhat dot com
                   ` (9 subsequent siblings)
  10 siblings, 0 replies; 12+ messages in thread
From: swagiaal at redhat dot com @ 2008-10-31 19:07 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #1 from swagiaal at redhat dot com  2008-10-31 19:06 -------
Created an attachment (id=16602)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16602&action=view)
testcase file 1 of 3 


-- 


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


^ permalink raw reply	[flat|nested] 12+ messages in thread

* [Bug debug/37982] Extranious DW_TAG_variable tag
  2008-10-31 19:05 [Bug debug/37982] New: Extranious DW_TAG_variable tag swagiaal at redhat dot com
  2008-10-31 19:07 ` [Bug debug/37982] " swagiaal at redhat dot com
  2008-10-31 19:08 ` swagiaal at redhat dot com
@ 2008-10-31 19:08 ` swagiaal at redhat dot com
  2008-11-01 11:05 ` [Bug debug/37982] Extraneous " dodji at gcc dot gnu dot org
                   ` (7 subsequent siblings)
  10 siblings, 0 replies; 12+ messages in thread
From: swagiaal at redhat dot com @ 2008-10-31 19:08 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #3 from swagiaal at redhat dot com  2008-10-31 19:07 -------
Created an attachment (id=16604)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16604&action=view)
testcase file 3 of 3


-- 


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


^ permalink raw reply	[flat|nested] 12+ messages in thread

* [Bug debug/37982] Extranious DW_TAG_variable tag
  2008-10-31 19:05 [Bug debug/37982] New: Extranious DW_TAG_variable tag swagiaal at redhat dot com
  2008-10-31 19:07 ` [Bug debug/37982] " swagiaal at redhat dot com
@ 2008-10-31 19:08 ` swagiaal at redhat dot com
  2008-10-31 19:08 ` swagiaal at redhat dot com
                   ` (8 subsequent siblings)
  10 siblings, 0 replies; 12+ messages in thread
From: swagiaal at redhat dot com @ 2008-10-31 19:08 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #2 from swagiaal at redhat dot com  2008-10-31 19:07 -------
Created an attachment (id=16603)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16603&action=view)
testcase file 2 of 3


-- 


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


^ permalink raw reply	[flat|nested] 12+ messages in thread

* [Bug debug/37982] Extraneous DW_TAG_variable tag
  2008-10-31 19:05 [Bug debug/37982] New: Extranious DW_TAG_variable tag swagiaal at redhat dot com
                   ` (2 preceding siblings ...)
  2008-10-31 19:08 ` swagiaal at redhat dot com
@ 2008-11-01 11:05 ` dodji at gcc dot gnu dot org
  2008-11-28  1:38 ` jan dot kratochvil at redhat dot com
                   ` (6 subsequent siblings)
  10 siblings, 0 replies; 12+ messages in thread
From: dodji at gcc dot gnu dot org @ 2008-11-01 11:05 UTC (permalink / raw)
  To: gcc-bugs

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2413 bytes --]



------- Comment #4 from dodji at gcc dot gnu dot org  2008-11-01 11:03 -------
I could reproduce this on 4.3 and trunk (4.4).

Actually I think there are several problems here.

First, I think the DIE representing the defining declaration of A::elsewhere in
class2.c should have a DW_AT_specification pointing back to the DIE
representing the declaration or A::elsewhere in class.h.

That can be deduced from the dwarf2 spec, section [4.1 Data Object Entries],
point 5, pdf page 35, spec page 33 that reads:
"5. If the variable entry represents the defining declaration for a C++ static
data member of a structure, class or union, the entry has a DW_AT_specification
attribute, whose value is a reference to the debugging information entry
representing the declaration of this data member. The referenced entry will be
a child of some class, structure or union type entry.".

Second, I think the DIE of the defining declaration of A::elsewhere in class2
should have a DW_AT_const_value attribute whose value should be the constant
"211".

This can be deduced from the dwarf2 spec, section [4.1 Data Object Entries],
point 9, pdf page 35, spec page 33 that reads:

"9. An entry describing a variable whose value is constant and not represented
by an object in the address space of the program, or an entry describing a
named constant, does not have a location attribute. Such entries have a
DW_AT_const_value attribute, whose value may be a string or any of the constant
data or data block forms, as appropriate for the representation of the
variable’s value. The value of this attribute is the actual constant value of
the variable, represented as it would be on the target architecture."

And third, as you pointed out, the DIE of the declaration of A::elsewhere
should not appear twice in the class.c compilation unit. It should only appear
once, in the scope of the A class.


-- 

dodji at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dodji at gcc dot gnu dot org
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2008-11-01 11:03:52
               date|                            |


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


^ permalink raw reply	[flat|nested] 12+ messages in thread

* [Bug debug/37982] Extraneous DW_TAG_variable tag
  2008-10-31 19:05 [Bug debug/37982] New: Extranious DW_TAG_variable tag swagiaal at redhat dot com
                   ` (3 preceding siblings ...)
  2008-11-01 11:05 ` [Bug debug/37982] Extraneous " dodji at gcc dot gnu dot org
@ 2008-11-28  1:38 ` jan dot kratochvil at redhat dot com
  2008-11-28 16:34 ` swagiaal at redhat dot com
                   ` (5 subsequent siblings)
  10 siblings, 0 replies; 12+ messages in thread
From: jan dot kratochvil at redhat dot com @ 2008-11-28  1:38 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #5 from jan dot kratochvil at redhat dot com  2008-11-28 01:36 -------
(In reply to comment #4)
> First, I think the DIE representing the defining declaration of A::elsewhere
> in class2.c should have a DW_AT_specification pointing back to the DIE
> representing the declaration or A::elsewhere in class.h.

Already present: non-defining declaration is <cf>, the defining declaration
is <ed>.  <ed> properly points by DW_AT_specification to its <cf>.


> Second, I think the DIE of the defining declaration of A::elsewhere in class2
> should have a DW_AT_const_value attribute whose value should be the constant
> "211".
> 
> This can be deduced from the dwarf2 spec, section [4.1 Data Object Entries],
> point 9, pdf page 35, spec page 33 that reads:
> 
> "9. An entry describing a variable whose value is constant and not represented
> by an object in the address space of the program, or an entry describing a
> named constant, does not have a location attribute.

DW_AT_const_value is more for Fortran constants which are an equivalent
of C #define.  In the sample code here `static const int' is in .rodata, it has
its address (DW_AT_location) and can be tracked by `rwatch' (read-watchpoint).

  [Nr] Name              Type             Address           Offset
       Size              EntSize          Flags  Link  Info  Align
  [15] .rodata           PROGBITS         0000000000400658  00000658
       0000000000000014  0000000000000000   A       0     0     8
Symbol table '.symtab' contains 73 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
    55: 0000000000400668     4 OBJECT  GLOBAL DEFAULT   15 _ZN1A9elsewhereE

It should be sufficient the type entry at <0xe1> (not shown in the sample dump
here) is already correctly DW_TAG_const_type.


> And third, as you pointed out, the DIE of the declaration of A::elsewhere
> should not appear twice in the class.c compilation unit. It should only appear
> once, in the scope of the A class.

Two vs. one DIE is not a mistake but more a minor optimization (such
optimization is already Bug debug/37941).

With single DIE it would look OK to me.  With two DIEs there are currently
these problems:

(1) DW_AT_name is now `elsewhere' while it should be either `A::elsewhere'
    or whole DW_TAG_variable should be enclosed by DW_TAG_class_type for `A'.
    It may be Bug c++/37590.
    (Non-standard DW_AT_MIPS_linkage_name should be removed in the future.)

(2) Defining declaration <86> should point by DW_AT_specification to its
    non-defining declaration <37>.  (The DWARF citation is here from Dodji.)

(But I do not see these two problems as real issues for debugging.)


-- 


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


^ permalink raw reply	[flat|nested] 12+ messages in thread

* [Bug debug/37982] Extraneous DW_TAG_variable tag
  2008-10-31 19:05 [Bug debug/37982] New: Extranious DW_TAG_variable tag swagiaal at redhat dot com
                   ` (4 preceding siblings ...)
  2008-11-28  1:38 ` jan dot kratochvil at redhat dot com
@ 2008-11-28 16:34 ` swagiaal at redhat dot com
  2008-11-29  0:25 ` jan dot kratochvil at redhat dot com
                   ` (4 subsequent siblings)
  10 siblings, 0 replies; 12+ messages in thread
From: swagiaal at redhat dot com @ 2008-11-28 16:34 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #6 from swagiaal at redhat dot com  2008-11-28 16:33 -------

> (2) Defining declaration <86> should point by DW_AT_specification to its
>     non-defining declaration <37>.  (The DWARF citation is here from Dodji.)
> 
> (But I do not see these two problems as real issues for debugging.)
> 

I ran into this issue because gdb was only reading die 0x86 for variable
'elsewhere' (I have not looked into why). The problem is that without proper
scoping on an abstract_origin attribute, so the correct canonical name for this
variable cannot be constructed (without relying on DW_AT_MIPS_linkage_name that
is). Therefore a 'print A::elsewhere' command fails


-- 


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


^ permalink raw reply	[flat|nested] 12+ messages in thread

* [Bug debug/37982] Extraneous DW_TAG_variable tag
  2008-10-31 19:05 [Bug debug/37982] New: Extranious DW_TAG_variable tag swagiaal at redhat dot com
                   ` (5 preceding siblings ...)
  2008-11-28 16:34 ` swagiaal at redhat dot com
@ 2008-11-29  0:25 ` jan dot kratochvil at redhat dot com
  2008-12-01 16:13 ` swagiaal at redhat dot com
                   ` (3 subsequent siblings)
  10 siblings, 0 replies; 12+ messages in thread
From: jan dot kratochvil at redhat dot com @ 2008-11-29  0:25 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #7 from jan dot kratochvil at redhat dot com  2008-11-29 00:23 -------
(In reply to comment #6)
> I ran into this issue because gdb was only reading die 0x86 for variable
> 'elsewhere' (I have not looked into why). The problem is that without proper
> scoping on an abstract_origin attribute, so the correct canonical name for
> this variable cannot be constructed (without relying
> on DW_AT_MIPS_linkage_name that is). Therefore a 'print A::elsewhere' command
> fails

DW_AT_MIPS_linkage_name should be removed from GCC only after the DW_AT_name
scoping/qualification will get fully fixed.  GDB currently already contains the
DW_AT_MIPS_linkage_name reader and there is probably no need to disable it
(except for testing purposes).

On GDB CVS HEAD for gdb.cp/m-static.exp a command `print gnu_obj_4::elsewhere'
works for me as it can find (presumably) the corrent .symtab mangled symbol.

Sure it would be good to get DW_AT_name fixed in GCC.


-- 


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


^ permalink raw reply	[flat|nested] 12+ messages in thread

* [Bug debug/37982] Extraneous DW_TAG_variable tag
  2008-10-31 19:05 [Bug debug/37982] New: Extranious DW_TAG_variable tag swagiaal at redhat dot com
                   ` (6 preceding siblings ...)
  2008-11-29  0:25 ` jan dot kratochvil at redhat dot com
@ 2008-12-01 16:13 ` swagiaal at redhat dot com
  2010-03-17 21:15 ` dodji at gcc dot gnu dot org
                   ` (2 subsequent siblings)
  10 siblings, 0 replies; 12+ messages in thread
From: swagiaal at redhat dot com @ 2008-12-01 16:13 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #8 from swagiaal at redhat dot com  2008-12-01 16:12 -------
> DW_AT_MIPS_linkage_name should be removed from GCC only after the DW_AT_name
> scoping/qualification will get fully fixed.  GDB currently already contains the
> DW_AT_MIPS_linkage_name reader and there is probably no need to disable it
> (except for testing purposes).
> 

Agreed. My patch fixes test cases where DW_AT_MIPS_linkage_name was not
generated by gcc, but the patch should be smarter about falling back on
DW_AT_MIPS_linkage_name when the correct canonical name cannot be constructed.

> On GDB CVS HEAD for gdb.cp/m-static.exp a command `print gnu_obj_4::elsewhere'
> works for me as it can find (presumably) the corrent .symtab mangled symbol.
> 
> Sure it would be good to get DW_AT_name fixed in GCC.
> 


-- 


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


^ permalink raw reply	[flat|nested] 12+ messages in thread

* [Bug debug/37982] Extraneous DW_TAG_variable tag
  2008-10-31 19:05 [Bug debug/37982] New: Extranious DW_TAG_variable tag swagiaal at redhat dot com
                   ` (7 preceding siblings ...)
  2008-12-01 16:13 ` swagiaal at redhat dot com
@ 2010-03-17 21:15 ` dodji at gcc dot gnu dot org
  2010-03-18 12:53 ` dodji at gcc dot gnu dot org
  2010-03-18 12:53 ` dodji at gcc dot gnu dot org
  10 siblings, 0 replies; 12+ messages in thread
From: dodji at gcc dot gnu dot org @ 2010-03-17 21:15 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #9 from dodji at gcc dot gnu dot org  2010-03-17 21:15 -------
The situation has change quite a lot since gcc 4.3.0.
Now a DW_TAG_member is emitted for the static member variable, and only one
DW_TAG_variable is emitted to represent the variable definition.

So I guess the bug can be closed now?

With 4.5 I get this:

<0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
    < c>   DW_AT_producer    : (indirect string, offset: 0x62): GNU C++ 4.5.0
20100301 (experimental)
    <10>   DW_AT_language    : 4        (C++)
    <11>   DW_AT_name        : (indirect string, offset: 0x0): class.c
    <15>   DW_AT_comp_dir    : (indirect string, offset: 0x19):
/home/dodji/devel/git/gcc-branches.git/gcc-PR37982.git/prtests
    <19>   DW_AT_low_pc      : 0x4004b4
    <21>   DW_AT_high_pc     : 0x4004c0
    <29>   DW_AT_stmt_list   : 0x0
 <1><2d>: Abbrev Number: 2 (DW_TAG_structure_type)
    <2e>   DW_AT_name        : A
    <30>   DW_AT_byte_size   : 1
    <31>   DW_AT_decl_file   : 2
    <32>   DW_AT_decl_line   : 2
    <33>   DW_AT_sibling     : <0x49>
 <2><37>: Abbrev Number: 3 (DW_TAG_member)
    <38>   DW_AT_name        : (indirect string, offset: 0x58): elsewhere
<3c>   DW_AT_decl_file   : 2
    <3d>   DW_AT_decl_line   : 3
    <3e>   DW_AT_MIPS_linkage_name: (indirect string, offset: 0x8):
_ZN1A9elsewhereE
    <42>   DW_AT_type        : <0x49>
    <46>   DW_AT_external    : 1
    <47>   DW_AT_declaration : 1

[...]

<0><a0>: Abbrev Number: 1 (DW_TAG_compile_unit)
    <a1>   DW_AT_producer    : (indirect string, offset: 0x62): GNU C++ 4.5.0
20100301 (experimental)
    <a5>   DW_AT_language    : 4        (C++)
    <a6>   DW_AT_name        : (indirect string, offset: 0x8d): class2.c
    <aa>   DW_AT_comp_dir    : (indirect string, offset: 0x19):
/home/dodji/devel/git/gcc-branches.git/gcc-PR37982.git/prtests
    <ae>   DW_AT_low_pc      : 0x4004c0
    <b6>   DW_AT_high_pc     : 0x4004c0
    <be>   DW_AT_stmt_list   : 0x46
 <1><c2>: Abbrev Number: 2 (DW_TAG_structure_type)
    <c3>   DW_AT_name        : A
    <c5>   DW_AT_byte_size   : 1
    <c6>   DW_AT_decl_file   : 1
    <c7>   DW_AT_decl_line   : 2
    <c8>   DW_AT_sibling     : <0xde>
 <2><cc>: Abbrev Number: 3 (DW_TAG_member)
    <cd>   DW_AT_name        : (indirect string, offset: 0x58): elsewhere
    <d1>   DW_AT_decl_file   : 1
    <d2>   DW_AT_decl_line   : 3
    <d3>   DW_AT_MIPS_linkage_name: (indirect string, offset: 0x8):
_ZN1A9elsewhereE
    <d7>   DW_AT_type        : <0xde>
    <db>   DW_AT_external    : 1
    <dc>   DW_AT_declaration : 1

[...]

<1><ea>: Abbrev Number: 6 (DW_TAG_variable)
    <eb>   DW_AT_specification: <0xcc>
    <ef>   DW_AT_decl_file   : 2
    <f0>   DW_AT_decl_line   : 2
    <f1>   DW_AT_location    : 9 byte block: 3 ac 5 40 0 0 0 0 0       
(DW_OP_addr: 4005ac)


-- 


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


^ permalink raw reply	[flat|nested] 12+ messages in thread

* [Bug debug/37982] Extraneous DW_TAG_variable tag
  2008-10-31 19:05 [Bug debug/37982] New: Extranious DW_TAG_variable tag swagiaal at redhat dot com
                   ` (8 preceding siblings ...)
  2010-03-17 21:15 ` dodji at gcc dot gnu dot org
@ 2010-03-18 12:53 ` dodji at gcc dot gnu dot org
  2010-03-18 12:53 ` dodji at gcc dot gnu dot org
  10 siblings, 0 replies; 12+ messages in thread
From: dodji at gcc dot gnu dot org @ 2010-03-18 12:53 UTC (permalink / raw)
  To: gcc-bugs



-- 

dodji at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |dodji at gcc dot gnu dot org
                   |dot org                     |
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2008-11-01 11:03:52         |2010-03-18 12:52:49
               date|                            |
   Target Milestone|---                         |4.5.0


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


^ permalink raw reply	[flat|nested] 12+ messages in thread

* [Bug debug/37982] Extraneous DW_TAG_variable tag
  2008-10-31 19:05 [Bug debug/37982] New: Extranious DW_TAG_variable tag swagiaal at redhat dot com
                   ` (9 preceding siblings ...)
  2010-03-18 12:53 ` dodji at gcc dot gnu dot org
@ 2010-03-18 12:53 ` dodji at gcc dot gnu dot org
  10 siblings, 0 replies; 12+ messages in thread
From: dodji at gcc dot gnu dot org @ 2010-03-18 12:53 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #10 from dodji at gcc dot gnu dot org  2010-03-18 12:53 -------
Bug no more present in 4.5


-- 

dodji at gcc dot gnu dot org changed:

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


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


^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2010-03-18 12:53 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-10-31 19:05 [Bug debug/37982] New: Extranious DW_TAG_variable tag swagiaal at redhat dot com
2008-10-31 19:07 ` [Bug debug/37982] " swagiaal at redhat dot com
2008-10-31 19:08 ` swagiaal at redhat dot com
2008-10-31 19:08 ` swagiaal at redhat dot com
2008-11-01 11:05 ` [Bug debug/37982] Extraneous " dodji at gcc dot gnu dot org
2008-11-28  1:38 ` jan dot kratochvil at redhat dot com
2008-11-28 16:34 ` swagiaal at redhat dot com
2008-11-29  0:25 ` jan dot kratochvil at redhat dot com
2008-12-01 16:13 ` swagiaal at redhat dot com
2010-03-17 21:15 ` dodji at gcc dot gnu dot org
2010-03-18 12:53 ` dodji at gcc dot gnu dot org
2010-03-18 12:53 ` dodji at gcc dot gnu dot org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).