[Bug debug/43254] New: [4.5 Regression] warning: DWARFDebugInfoEntry::AppendDependants() -- check on this item TAG_subrange_type: attr = AT_upper_bound form = FORM_ref4

[Bug debug/43254] New: [4.5 Regression] warning: DWARFDebugInfoEntry::AppendDependants() -- check on this item TAG_subrange_type: attr = AT_upper_bound form = FORM_ref4

[dominiq at lps dot ens dot fr]

Between revisions 157150 and 157190 (likely the latter) it appeared the
following failures on *-apple-darwin*:

FAIL: gcc.c-torture/execute/20020412-1.c compilation,  -O3 -g 
UNRESOLVED: gcc.c-torture/execute/20020412-1.c execution,  -O3 -g 
FAIL: gcc.c-torture/execute/20040811-1.c compilation,  -O3 -g 
UNRESOLVED: gcc.c-torture/execute/20040811-1.c execution,  -O3 -g 
FAIL: gcc.c-torture/execute/pr43220.c compilation,  -O3 -g 
UNRESOLVED: gcc.c-torture/execute/pr43220.c execution,  -O3 -g 
FAIL: gcc.c-torture/execute/vla-dealloc-1.c compilation,  -O3 -g 
UNRESOLVED: gcc.c-torture/execute/vla-dealloc-1.c execution,  -O3 -g 

When run manually the output is

[macbook] f90/bug% gcc45 -save-temps -O3 -g
/opt/gcc/work/gcc/testsuite/gcc.c-torture/execute/20040811-1.c
warning: DWARFDebugInfoEntry::AppendDependants() -- check on this item
TAG_subrange_type: attr =  AT_upper_bound  form = FORM_ref4

Since this warning is harmless I don't understand why the compilation fails and
the execution is UNRESOLVED (the executable works fine).

Note that I have reported a similar problem in comment#89 of pr41473 (
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473#c89 ).

I'll attach the assembly for r157098 (no warning) and r157190 (warning).


-- 
           Summary: [4.5 Regression] warning:
                    DWARFDebugInfoEntry::AppendDependants() -- check on this
                    item TAG_subrange_type: attr =  AT_upper_bound  form =
                    FORM_ref4
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: debug
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: dominiq at lps dot ens dot fr
 GCC build triplet: *-apple-darwin*
  GCC host triplet: *-apple-darwin*
GCC target triplet: *-apple-darwin*


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

[Bug debug/43254] [4.5 Regression] warning: DWARFDebugInfoEntry::AppendDependants() -- check on this item TAG_subrange_type: attr = AT_upper_bound form = FORM_ref4

[dominiq at lps dot ens dot fr]

------- Comment #1 from dominiq at lps dot ens dot fr  2010-03-04 12:10 -------
Created an attachment (id=20018)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20018&action=view)
assembly for r157190 (warning)


-- 


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

[Bug debug/43254] [4.5 Regression] warning: DWARFDebugInfoEntry::AppendDependants() -- check on this item TAG_subrange_type: attr = AT_upper_bound form = FORM_ref4

[dominiq at lps dot ens dot fr]

------- Comment #2 from dominiq at lps dot ens dot fr  2010-03-04 12:12 -------
Created an attachment (id=20019)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20019&action=view)
assembly for r157098 (no warning) of gcc.c-torture/execute/20040811-1.c


-- 


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

[Bug debug/43254] [4.5 Regression] warning: DWARFDebugInfoEntry::AppendDependants() -- check on this item TAG_subrange_type: attr = AT_upper_bound form = FORM_ref4

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.5.0


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

[Bug debug/43254] [4.5 Regression] warning: DWARFDebugInfoEntry::AppendDependants() -- check on this item TAG_subrange_type: attr = AT_upper_bound form = FORM_ref4

[jakub at gcc dot gnu dot org]

------- Comment #3 from jakub at gcc dot gnu dot org  2010-03-04 13:39 -------
DW_AT_upper_bound can be either a constant, or exprloc, or reference (this
case), so if dsymutil chokes on it, it needs to be fixed.


-- 


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

[Bug debug/43254] [4.5 Regression] warning: DWARFDebugInfoEntry::AppendDependants() -- check on this item TAG_subrange_type: attr = AT_upper_bound form = FORM_ref4

[rguenth at gcc dot gnu dot org]

------- Comment #4 from rguenth at gcc dot gnu dot org  2010-03-10 16:26 -------
dsymutil bug


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


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

[Bug debug/43254] [4.5 Regression] warning: DWARFDebugInfoEntry::AppendDependants() -- check on this item TAG_subrange_type: attr = AT_upper_bound form = FORM_ref4

[iains at gcc dot gnu dot org]

------- Comment #5 from iains at gcc dot gnu dot org  2010-04-11 22:52 -------
It's possible that the message from dsymutil is misleading:

Is this correct ?  
I'm very new to dwarf - but it looks like the DW_AT_upper_bound is missing a
value?

        .byte   0x6     # uleb128 0x6; (DIE (0x10d) DW_TAG_base_type)
        .byte   0x4     # DW_AT_byte_size
        .byte   0x5     # DW_AT_encoding
        .ascii "int\0"  # DW_AT_name
        .byte   0x7     # uleb128 0x7; (DIE (0x114) DW_TAG_array_type)
        .long   0x10d   # DW_AT_type
        .long   0x127   # DW_AT_sibling
        .byte   0x8     # uleb128 0x8; (DIE (0x11d) DW_TAG_subrange_type)
        .long   0x127   # DW_AT_type
        .long   0xf5    # DW_AT_upper_bound
        .byte   0x0     # end of children of DIE 0x114
        .byte   0x9     # uleb128 0x9; (DIE (0x127) DW_TAG_base_type)


-- 

iains at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |


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

[Bug debug/43254] [4.5 Regression] warning: DWARFDebugInfoEntry::AppendDependants() -- check on this item TAG_subrange_type: attr = AT_upper_bound form = FORM_ref4

[howarth at nitro dot med dot uc dot edu]

------- Comment #6 from howarth at nitro dot med dot uc dot edu  2010-04-11 23:42 -------
Opened radar://7851516 and have pinged the Apple dsymutil maintainer to take a
look.


-- 


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

[Bug debug/43254] [4.5 Regression] warning: DWARFDebugInfoEntry::AppendDependants() -- check on this item TAG_subrange_type: attr = AT_upper_bound form = FORM_ref4

[iains at gcc dot gnu dot org]

------- Comment #7 from iains at gcc dot gnu dot org  2010-04-12 00:55 -------
 this causes the message at any optimization > 0.
which kinda points to variable length arrays as the issue (wherever that issue
is).

extern long random(void);
int main(int ac,char *av[])
{
  int n = random();
  int x[n+1];
  return 0;   
}


-- 


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

[Bug debug/43254] [4.5 Regression] warning: DWARFDebugInfoEntry::AppendDependants() -- check on this item TAG_subrange_type: attr = AT_upper_bound form = FORM_ref4

[howarth at nitro dot med dot uc dot edu]

------- Comment #8 from howarth at nitro dot med dot uc dot edu  2010-04-12 01:54 -------
The response from the dsymutil maintainer was...

The warning was cause for alarm, and the root cause has been fixed (checked
in), though it isn't affecting your test case.

If you see this type of warning again before you get a fixed dsymutil, look at
the dwarfdump output as you were doing for a matching attribute value. In this
case it was:

0x00000205:         TAG_subrange_type [28]
                     AT_type[FORM_ref4] ( {0x00000048} ( base  ) )
                     AT_upper_bound[FORM_ref4] ( {0x00000149} )

Then you want to make sure that the reference (FORM_ref4) it has ({0x00000149})
made it into the output file which it did:

0x00000149:         TAG_variable [21]
                     AT_artificial[FORM_flag] ( 0x01 )
                     AT_type[FORM_ref4] ( {0x0000020f} ( const base  ) )
                     AT_location[FORM_data4] ( 0x00000144
                        0x0000000100000d46 - 0x0000000100000e62: r13-1
                        0x0000000100000e64 - 0x0000000100000e6f: r13-1 )


So everything is ok in this case.

dsymutil will track exactly which DIEs make it into the dSYM and only put those
DIEs and the dependent DIEs. This helps deal with gcc's one definition rule
which can bloat up the debug info. If dead code stripping is on, and only one
function of 100 makes it into the dSYM, we strip 99% of the debug info and keep
the DWARF small. In a failing case, dsymutil would not add 0x00000149 to the
output dSYM and the DWARF would have a DIE with an invalid reference.


-- 


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

[Bug debug/43254] [4.5 Regression] warning: DWARFDebugInfoEntry::AppendDependants() -- check on this item TAG_subrange_type: attr = AT_upper_bound form = FORM_ref4

[howarth at nitro dot med dot uc dot edu]

------- Comment #9 from howarth at nitro dot med dot uc dot edu  2010-04-12 03:25 -------
I confirmed with the dsymutil maintainer that my reading of his response was
correct. Indeed, the warning may or may not be significant and has to be
checked for each instance. So if all four test cases are actually emitting
valid dwarf, we can drop the usage of -lm on darwin[921] (although we will have
to
add a dg-prune-output to eliminate the failures from these false warnings.


-- 


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

[Bug debug/43254] [4.5 Regression] warning: DWARFDebugInfoEntry::AppendDependants() -- check on this item TAG_subrange_type: attr = AT_upper_bound form = FORM_ref4

[iains at gcc dot gnu dot org]

------- Comment #10 from iains at gcc dot gnu dot org  2010-04-12 06:43 -------
(In reply to comment #9)
> I confirmed with the dsymutil maintainer that my reading of his response was
> correct. Indeed, the warning may or may not be significant and has to be
> checked for each instance. So if all four test cases are actually emitting
> valid dwarf, we can drop the usage of -lm on darwin[921] (although we will have
> to
> add a dg-prune-output to eliminate the failures from these false warnings.

OK, sorry for the noise on the list.

We will, however, have to figure out what to do for D9.. and D8... since we
can't expect a fix there.. I suppose.


-- 

iains at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


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

[Bug debug/43254] [4.5 Regression] warning: DWARFDebugInfoEntry::AppendDependants() -- check on this item TAG_subrange_type: attr = AT_upper_bound form = FORM_ref4

[iains at gcc dot gnu dot org]

------- Comment #11 from iains at gcc dot gnu dot org  2010-04-12 06:57 -------
(In reply to comment #9)
> checked for each instance. So if all four test cases are actually emitting
> valid dwarf, we can drop the usage of -lm on darwin[921] 

The two things are totally unrelated - AFAICT the reason the "-lm" causes the
problem to "go away" is because of a specs bug causing dsymutil not to run when
"-lm" is on the C/L.

So we WILL have to find a solution - because we need to fix the specs bug and
the use of "-lm". ;) 


-- 


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

[Bug debug/43254] [4.5 Regression] warning: DWARFDebugInfoEntry::AppendDependants() -- check on this item TAG_subrange_type: attr = AT_upper_bound form = FORM_ref4

[jakub at gcc dot gnu dot org]

------- Comment #12 from jakub at gcc dot gnu dot org  2010-04-12 08:21 -------
GCC would ICE if the referenced DIE wasn't being output on:
gcc_assert (AT_ref (a)->die_offset);
in output_die.


-- 


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

[Bug debug/43254] [4.5 Regression] warning: DWARFDebugInfoEntry::AppendDependants() -- check on this item TAG_subrange_type: attr = AT_upper_bound form = FORM_ref4

[iains at gcc dot gnu dot org]

------- Comment #13 from iains at gcc dot gnu dot org  2010-04-12 13:28 -------
Created an attachment (id=20364)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20364&action=view)
hack wrapper for dsymutil

This is a simple script that edits one specific warning out of the output from
dsymutil.
The warning can be re-enabled by passing -Wdsymutil as the first item on the
CL.

It needs to be in your PATH - I haven't tried to do anything towards
integrating this into gcc.


-- 


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

[Bug debug/43254] [4.5 Regression] warning: DWARFDebugInfoEntry::AppendDependants() -- check on this item TAG_subrange_type: attr = AT_upper_bound form = FORM_ref4

[iains at gcc dot gnu dot org]

------- Comment #14 from iains at gcc dot gnu dot org  2010-04-12 13:36 -------
Created an attachment (id=20365)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20365&action=view)
sort out some nits with config/{*,}/darwin*.h and hack in a solution for
dsymtuil

The dsymutils issue is not a GCC bug - but it is a problem that gcc darwin
developers need to deal with in the short to medium term (possibly long-term
for darwin<10) ... 

OK, this is a patch which is work in progress to clean up darwin*.h:

(a) clear up some nits in the spacing of asm directives
(b) make sure that we only need to maintain one LINK_COMMAND_SPEC -

and ... now ... 
(c) provide a hack to get round the dsymtuils problem

this is NOT a proposed patch to solve the problem - but it is a patch to allow
things to proceed for developers without being inundated with error messages.

I've made the dsymutils produce flat files for the output (.dwarf) which seem
to work fine with the XCode gdb and avoid the "dSYM is a directory" config
warnings.

debug is working for fortran with this but ONLY if you put -save-temps on the
C/L .. dunno why that is yet.. (-pipe doesn't solve it).

-====-
Perhaps someone could look at how this can be packaged so that we can use it
for things like "regress"?


-- 


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

[Bug debug/43254] [4.5 Regression] warning: DWARFDebugInfoEntry::AppendDependants() -- check on this item TAG_subrange_type: attr = AT_upper_bound form = FORM_ref4

[iains at gcc dot gnu dot org]

------- Comment #15 from iains at gcc dot gnu dot org  2010-04-12 13:39 -------
(In reply to comment #12)
> GCC would ICE if the referenced DIE wasn't being output on:
> gcc_assert (AT_ref (a)->die_offset);
> in output_die.

thanks Jakub, 
for now we need to work around this .. 
(a) until dsymutils are fixed for darwin9 (a long wait possibly)
(b) or they are Open Sourced (no idea what the block is to that)
(c) someone has time to roll our own .. (tempting - but there are more pressing
things on my time).


-- 


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

[Bug debug/43254] [4.5 Regression] warning: DWARFDebugInfoEntry::AppendDependants() -- check on this item TAG_subrange_type: attr = AT_upper_bound form = FORM_ref4

[iains at gcc dot gnu dot org]

------- Comment #16 from iains at gcc dot gnu dot org  2010-04-14 17:37 -------
see: 
http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00806.html
for a proposed resolution to this.


-- 


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

[Bug debug/43254] [4.5 Regression] warning: DWARFDebugInfoEntry::AppendDependants() -- check on this item TAG_subrange_type: attr = AT_upper_bound form = FORM_ref4

[howarth at nitro dot med dot uc dot edu]

------- Comment #17 from howarth at nitro dot med dot uc dot edu  2010-08-04 19:20 -------
Unverified but I am told that this issue should be fixed in Xcode 3.2.3.


-- 


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

[Bug debug/43254] [4.5 Regression] warning: DWARFDebugInfoEntry::AppendDependants() -- check on this item TAG_subrange_type: attr = AT_upper_bound form = FORM_ref4

[dominiq at lps dot ens dot fr]

------- Comment #18 from dominiq at lps dot ens dot fr  2010-08-05 07:04 -------
> Unverified but I am told that this issue should be fixed in Xcode 3.2.3.

AFAICT it is.


-- 


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