Bug 459374 - Bug report: Gfortran emits bad DWARF for array parameters.
Bug report: Gfortran emits bad DWARF for array parameters.
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: gcc44 (Show other bugs)
All Linux
medium Severity medium
: rc
: ---
Assigned To: Jakub Jelinek
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2008-08-17 21:41 EDT by Issue Tracker
Modified: 2010-10-22 23:48 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-09-02 07:43:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
reproducer (832 bytes, text/plain)
2008-08-17 21:43 EDT, Jatin Nansi
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2009:1375 normal SHIPPED_LIVE gcc44 bug fix and enhancement update 2009-09-01 07:21:22 EDT

  None (edit)
Description Issue Tracker 2008-08-17 21:41:43 EDT
Escalated to Bugzilla from IssueTracker
Comment 1 Issue Tracker 2008-08-17 21:41:44 EDT
This ticket was created by LLNL and first forwarded to Etnus's support organization for TotalView but after analyzing the issue, they have come to believe that it is a problem with the way that gfortran emits DWARF information.

Gfortran emits bad DWARF for array parameters. Upper bound is missing.

rhel52-x8664:/home/seppo/Bugs/Bug_11350 > cat /etc/*-rel*
cat: /etc/lsb-release.d: Is a directory
Red Hat Enterprise Linux Server release 5.2 (Tikanga)
rhel52-x8664:/home/seppo/Bugs/Bug_11350 > uname -a
Linux rhel52-x8664.totalviewtech.com 2.6.18-92.el5 #1 SMP Tue Apr 29 13:16:15 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux
rhel52-x8664:/home/seppo/Bugs/Bug_11350 >

> gfortran -v
gcc version 4.1.2 20071124 (Red Hat 4.1.2-42)

> gfortran -g -O0 -o a_g.out tx_f90_contained_sub.f90

> readelf -w ./a_g.out

     DW_AT_location    : 3 byte block: 91 f8 7d         (DW_OP_fbreg: -264)
 <2><12a>: Abbrev Number: 10 (DW_TAG_formal_parameter)
     DW_AT_name        : c_sub
     DW_AT_decl_file   : 1
     DW_AT_decl_line   : 22
     DW_AT_type        : <232>
     DW_AT_location    : 3 byte block: 91 f0 7d         (DW_OP_fbreg: -272)
 <2><13b>: Abbrev Number: 10 (DW_TAG_formal_parameter)
     DW_AT_name        : c_size
     DW_AT_type        : <1e0>
 <1><222>: Abbrev Number: 17 (DW_TAG_array_type)
     DW_AT_sibling     : <232>
     DW_AT_type        : <e2>
 <2><22b>: Abbrev Number: 18 (DW_TAG_subrange_type)
     DW_AT_type        : <7f>
     DW_AT_lower_bound : 0
 <1><232>: Abbrev Number: 16 (DW_TAG_const_type)
     DW_AT_type        : <237>
 <1><237>: Abbrev Number: 19 (DW_TAG_pointer_type)
     DW_AT_byte_size   : 8
     DW_AT_type        : <222>
 <1><23d>: Abbrev Number: 16 (DW_TAG_const_type)

=> the problem is that for array c_sub, only DW_AT_lower_bound is
defined in DWARF. DW_AT_upper_bound is missing in <22b> entry.

Reproducer is attached.

This is TotalView internal bug #11350

This event sent from IssueTracker by jnansi  [Support Engineering Group]
 issue 198958
Comment 2 Issue Tracker 2008-08-17 21:41:46 EDT
Date problem reported: 8-12-08

Problem: Gfortran emits bad DWARF for array parameters.

This issue was originally escalated to Etnus by LLNL as a TotalView bug,
but, Etnus has come back and said that the problem appears to be with
gfortran instead.

To reproduce:

1) rename the attached program so that it has an .f90 extension, rather
than a .f one.  

2) compile the program with: 

gfortran -g -O0 -o a_g.out bad-dwarf-array-params.f90

3) readelf -w ./a_g.out

According to Etnus, the problem is that for array c_sub, only
DW_AT_lower_bound is defined in DWARF. DW_AT_upper_bound is missing in the
<22b> entry.

What is expected from SEG:  As with some previous gfortran problems we
submitted, these are kind of over our heads, and we need someone well
versed in gfortran to review this and determine if we have a bug here that
needs fixing.

This does appear to reproduce on my RHEL5.2 test system.


Issue escalated to Support Engineering Group by: kbaxley.
kbaxley assigned to issue for LLNL (HPC).
Category set to: Devel Tools
Internal Status set to 'Waiting on SEG'
Status set to: Waiting on Tech

This event sent from IssueTracker by jnansi  [Support Engineering Group]
 issue 198958
Comment 3 Jatin Nansi 2008-08-17 21:43:09 EDT
Created attachment 314457 [details]
Comment 4 Jatin Nansi 2008-08-17 21:46:04 EDT
Currently, we do not have anyone available in SEG familiar with fortran and DWARF, hence escalating to engineering.
Comment 6 Jakub Jelinek 2008-08-21 17:50:39 EDT
Patch http://gcc.gnu.org/ml/gcc-patches/2008-08/msg01599.html
Comment 7 Jakub Jelinek 2009-03-04 03:46:16 EST
This should be fixed in GCC 4.3/4.4, won't be fixed in 4.1.
Comment 8 Ben Woodard 2009-04-01 15:34:29 EDT
Which version of gcc 4.3 has this fixed in. I'm still getting reports that the version that ships with 5.3 still manifests this problem. If it is a version subsequent to 5.3 we can probably live with that but if it was supposedly fixed in the 5.3 release then we need to look deeper.
Comment 12 Jakub Jelinek 2009-04-03 06:11:02 EDT
The patch mentioned in #c6 really fixed the debuginfo for variable sized non-desc arrays, if you modify the testcase by moving the print statements from contained_sub to sub_test, it works with that patch just fine.

The extra problems are caused by the nested functions.  I guess one problem is type sharing between the contained and containing function:

  /* ??? We should be remapping types as well, surely.  */
  new_decl = build_decl (VAR_DECL, DECL_NAME (decl), TREE_TYPE (decl));

in get_nonlocal_debug_decl is one issue (we should be remapping the types in the nested function if they are variable length for debuginfo purposes, perhaps just at -O0), another issue is that get_local_debug_decl should replace (again, perhaps at -O0 only) vars in the VLA type ranges that were referenced by nested functions and last issue is that we don't allow DECL_BY_REFERENCE for VAR_DECLs (as the same bit is used for TREE_PRIVATE).
Comment 13 Jakub Jelinek 2009-04-08 12:11:45 EDT

The only problem after these patches is that a_sub symbol isn't in contained_sub's debuginfo, only in the outer function.
Comment 15 Jakub Jelinek 2009-04-22 10:15:15 EDT
Another patch on top of the two that solves the remaining issues, now
all of a_sub, b_sub and c_sub can be correctly printed both in both sub_test and contained_sub if they are referenced in both.
Comment 27 errata-xmlrpc 2009-09-02 07:43:09 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


Note You need to log in before you can comment on or make changes to this bug.