Re: target/6522: Incorrect struct offset for unaligned 64-bit fields in debug information

[Daniel Jacobowitz <drow@mvista.com>]

The following reply was made to PR target/6522; it has been noted by GNATS.

From: Daniel Jacobowitz <drow@mvista.com>
To: Jakub Jelinek <jakub@redhat.com>
Cc: fred@nextnewgig.com, gcc-bugs@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Subject: Re: target/6522: Incorrect struct offset for unaligned 64-bit fields in debug information
Date: Fri, 3 May 2002 13:32:54 -0400

 On Fri, May 03, 2002 at 06:20:33AM -0400, Jakub Jelinek wrote:
 > On Thu, May 02, 2002 at 09:32:08PM -0400, Daniel Jacobowitz wrote:
 > > On Tue, Apr 30, 2002 at 11:30:38PM -0000, jakub@gcc.gnu.org wrote:
 > > > Synopsis: Incorrect struct offset for unaligned 64-bit fields in debug information
 > > > 
 > > > State-Changed-From-To: open->feedback
 > > > State-Changed-By: jakub
 > > > State-Changed-When: Tue Apr 30 16:30:37 2002
 > > > State-Changed-Why:
 > > >     You have not provided t64.cpp (or better t64.ii if t64.cpp
 > > >     includes some headers).
 > > > 
 > > > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6522
 > > 
 > > I can confirm this in 3.1.  It's present in 3.0, but worked in 2.95.3. 
 > > It's quite annoying, since GDB can't infer the right answer.
 > 
 > Reproduced, looking into it.
 
 Thanks!
 
 > > Here's another example:
 > > 
 > > typedef __complex__ float cf;
 > > struct x { char c; cf f; } __attribute__ ((__packed__));
 > > struct unpacked_x { char c; cf f; };
 > > 
 > > Compile and compare the debug info; it does not respect __packed__.
 > 
 > This testcase has wrong debug info in 2.95.3 and
 > 2.96-RH, but looks correct in 3.0 and 3.1:
 >         .ascii "f\0"    # DW_AT_name
 >         .byte   0x1     # DW_AT_decl_file
 >         .byte   0x2     # DW_AT_decl_line
 >         .long   0x4f    # DW_AT_type
 >         .byte   0x2     # DW_AT_data_member_location
 >         .byte   0x23    # DW_OP_plus_uconst
 >         .uleb128 0x1
 > ^^^^^^^^^^^^^^^^^^^^
 > (this used to be 0x4 with older gcc's).
 
 Oh, you're right.  It fails in 3.0 with stabs information, which I
 reported to this list earlier and no one's had time to fix
 (http://gcc.gnu.org/ml/gcc-bugs/2002-01/msg01229.html; the closest
 to consensus was that we should start using 'R' instead of 'r', like
 Sun CC does). 
 
 -- 
 Daniel Jacobowitz                           Carnegie Mellon University
 MontaVista Software                         Debian GNU/Linux Developer