[Bug debug/86687] New: Wrong debug information for string types passed as parameters

[nikolay.piskun at roguewave dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86687

Bug ID: 86687
   Summary: Wrong debug information for string types passed as
parameters
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nikolay.piskun at roguewave dot com
  Target Milestone: ---

[Bug debug/86687] Wrong debug information for string types passed as parameters

[nikolay.piskun at roguewave dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86687

--- Comment #1 from Nikolay Piskun  ---
Created attachment 8
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=8&action=edit
Test program

How to reproduce; 
Set a breakpoint on line 48
Look at two variable: base (passed as reference) and dir_hint (passed as copy).
They should be the same values, but second one is wrong. Looks like compiler
passed it as reference ( type print *dir_hint), but debug information is
emitted as type class string. I think the problem is a mismatch. Compiler is
smart enough to realized, that data is shared among strings and put a reference
as parameter, but debug information is still for copy of value. Same proble, is
with shared QStrings and possibly other shared types.

[Bug debug/86687] Wrong debug information for string types passed as parameters

[nikolay.piskun at roguewave dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86687

--- Comment #2 from Nikolay Piskun  ---
How to reproduce; 
Set a breakpoint on line 48
Look at two variable: base (passed as reference) and dir_hint (passed as copy).
They should be the same values, but second one is wrong. Looks like compiler
passed it as reference ( type print *dir_hint), but debug information is
emitted as type class string. I think the problem is a mismatch. Compiler is
smart enough to realized, that data is shared among strings and put a reference
as parameter, but debug information is still for copy of value. Same proble, is
with shared QStrings and possibly other shared types.

[Bug debug/86687] Wrong debug information for string types passed as parameters

[nikolay.piskun at roguewave dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86687

--- Comment #12 from Nikolay Piskun  ---
Great work, thanks. Will this fix propagate to other branches?

[Bug debug/69785] New: c++filt can't demangle string or compiler produce wrong mangled string

[nikolay.piskun at roguewave dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69785

Bug ID: 69785
   Summary: c++filt can't demangle string or compiler produce
wrong mangled string
   Product: gcc
   Version: 4.8.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nikolay.piskun at roguewave dot com
  Target Milestone: ---

TotalView debugger emits demangling error, trying to demangle following string:

_ZN9__gnu_cxx13new_allocatorINSt8__detail10_Hash_nodeISt4pairIKiiELb09constructIS6_IRKSt21piecewise_construct_tSt5tupleIIRS4_EESC_IIEvPT_DpOT0_

c++filt can't demangle it either. Looks like the problem is in last "T0_" if
you just substitute it with v, then you get:
c++filt
_ZN9__gnu_cxx13new_allocatorINSt8__detail10_Hash_nodeISt4pairIKiiELb09constructIS6_IRKSt21piecewise_construct_tSt5tupleIIRS4_EESC_IIEvPT_DpOv
void __gnu_cxx::new_allocator, false> >::construct,
false>, std::tuple<>
> >(std::__detail::_Hash_node,
false>, std::tuple<>
>*, (void&&)...)

[Bug debug/69785] c++filt can't demangle string or compiler produce wrong mangled string

[nikolay.piskun at roguewave dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69785

--- Comment #1 from Nikolay Piskun  ---
I can send a test program, but its rather long.

[Bug fortran/77865] New: Regression: wrong debug information for gfortran pointers to structures

[nikolay.piskun at roguewave dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77865

Bug ID: 77865
   Summary: Regression: wrong debug information for gfortran
pointers to structures
   Product: gcc
   Version: 6.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nikolay.piskun at roguewave dot com
  Target Milestone: ---

Created attachment 39757
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=39757&action=edit
Test  program

Here is example of code that generate wrong debug information
type small_stride
  character*40 long_string
  integer  small_pad
end type small_stride

character*40, pointer, dimension(:):: c40pt
type(small_stride), dimension (20), target :: unpleasant
... Initialize unpleasant 
c40pt => unpleasant%long_string

gfortran 5.2 will produce following arrays bounds for c40pt:
<2><307>: Abbrev Number: 26 (DW_TAG_subrange_type)
<308>   DW_AT_lower_bound : 4 byte block: 97 23 20 6   
(DW_OP_push_object_address; DW_OP_plus_uconst: 32; DW_OP_deref)
<30d>   DW_AT_upper_bound : 4 byte block: 97 23 28 6   
(DW_OP_push_object_address; DW_OP_plus_uconst: 40; DW_OP_deref)
<312>   DW_AT_byte_stride : 9 byte block: 97 23 18 6 91 b0 7f 6 1e 
(DW_OP_push_object_address; DW_OP_plus_uconst: 24; DW_OP_deref; DW_OP_fbreg:
-80; DW_OP_deref; DW_OP_mul)

whereas gcc 6.2.0 lacks stride information. 

<2><307>: Abbrev Number: 26 (DW_TAG_subrange_type)
<308>   DW_AT_lower_bound : 4 byte block: 97 23 20 6   
(DW_OP_push_object_address; DW_OP_plus_uconst: 32; DW_OP_deref)
<30d>   DW_AT_upper_bound : 4 byte block: 97 23 28 6   
(DW_OP_push_object_address; DW_OP_plus_uconst: 40; DW_OP_deref)