This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug debug/8354] Incorrect DWARF-2/3 emitted for const + array
- From: "gary at intrepid dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 1 Jan 2007 22:47:41 -0000
- Subject: [Bug debug/8354] Incorrect DWARF-2/3 emitted for const + array
- References: <bug-8354-1506@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #12 from gary at intrepid dot com 2007-01-01 22:47 -------
Jim Wilson posted thi follow up to the GDB list:
http://sourceware.org/ml/gdb/2007-01/msg00007.html
From: Jim Wilson <wilson at specifix dot com>
Date: Mon, 01 Jan 2007 14:15:47 -0800
Subject: RE: how to support C type qualifiers applied to arrays?
On Thu, 2006-12-14 at 12:22 -0800, Gary Funck wrote:
> The main difficulty is that GCC doesn't create new qualified
> types for declarations. Rather, it sets TREE_READONLY()
> and TREE_THIS_VOLATILE() in the DECL node for declarations
> such as:
> volatile int A[10];
If you look at the types created by the C front end, they are OK.
c_build_qualified_type knows how to handle an array correctly.
The problem arises in the DWARF2 output code. gen_type_die calls
type_main_variant for all types other than vector types, which strips
off the const and volatile type modifiers. Then it clumsily tries to
put them back later in gen_variable_die, except that for array types, it
puts them back in the wrong place.
This seems to answer the question I asked long ago. Why are we trying
to put back qualifiers from the decl? Because gen_type_die stripped
them off. This seems wrong.
If we fix gen_type_die to stop calling type_main_variant, and if we fix
gen_variable_die to stop adding back the type qualifiers, then I get the
right result. So I think I was on the right track before, we just need
another little change to gen_type_die in addition to what I already
described.
I haven't investigated this in detail yet. There may be other parts of
the code that expect to see a type main variant here, so we might need
other cascading fixes. This still seems fixable to me though.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8354