public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "dberlin at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/22488] [4.1 Regression] C++ generates incorrect overlapping fields
Date: Tue, 27 Sep 2005 20:42:00 -0000	[thread overview]
Message-ID: <20050927204252.7956.qmail@sourceware.org> (raw)
In-Reply-To: <20050714141428.22488.micis@gmx.de>


------- Additional Comments From dberlin at gcc dot gnu dot org  2005-09-27 20:42 -------
We have   a var of type C named D.2117

 <var_decl 0x4022cec8 D.2117
    type <record_type 0x40212ac8 C addressable tree_2 needs-constructing type_1
type_4 type_5 BLK
        size <integer_cst 0x40210ed0 constant invariant 224>
        unit size <integer_cst 0x40210f00 constant invariant 28>
        align 32 symtab 0 alias set 21
        fields <field_decl 0x40212ebc D.1814 type <record_type 0x40212170 B>
            ignored decl_6 BLK file /home/dberlin/22488.cc line 18
            size <integer_cst 0x401693f0 constant invariant 32>
            unit size <integer_cst 0x40169180 constant invariant 4>
            align 32 offset_align 128
            offset <integer_cst 0x40169198 constant invariant 0>
            bit offset <integer_cst 0x40169960 constant invariant 0> context
<record_type 0x40212ac8 C> chain <field_decl 0x40212b24 x>>
       needs-constructor needs-destructor X() X(constX&) this=(X&) n_parents=1
use_template=0 interface-unknown
        pointer_to_this <pointer_type 0x40212c38> chain <type_decl 0x401eedd0 C>>
    addressable ignored BLK file /home/dberlin/22488.cc line 26 size
<integer_cst 0x40210ed0 224> unit size <integer_cst 0x40210f00 28>
    align 32 context <function_decl 0x40214680 foo>>

The first field of this is a field D.2184 of type B

 <field_decl 0x40212ebc D.1814
    type <record_type 0x40212170 B addressable tree_2 needs-constructing type_1
type_4 type_5 BLK
        size <integer_cst 0x40169660 constant invariant 128>
        unit size <integer_cst 0x40169678 constant invariant 16>
        align 32 symtab 0 alias set 2
        fields <field_decl 0x40212450 _vptr.B type <pointer_type 0x401f005c>
            unsigned virtual SI file /home/dberlin/22488.cc line 15
            size <integer_cst 0x401693f0 constant invariant 32>
            unit size <integer_cst 0x40169180 constant invariant 4>
            align 32 offset_align 128
            offset <integer_cst 0x40169198 constant invariant 0>
            bit offset <integer_cst 0x40169960 constant invariant 0> context
<record_type 0x40212170 B> chain <type_decl 0x401eec98 B>>
       needs-constructor needs-destructor X() X(constX&) this=(X&) n_parents=1
use_template=0 interface-unknown
        pointer_to_this <pointer_type 0x40212228> chain <type_decl 0x401eec30 B>>
    ignored decl_6 BLK file /home/dberlin/22488.cc line 18 size <integer_cst
0x401693f0 32> unit size <integer_cst 0x40169180 4>
    align 32 offset_align 128 offset <integer_cst 0x40169198 0> bit offset
<integer_cst 0x40169960 0> context <record_type 0x40212ac8 C> chain <field_decl
0x40212b24 x>>

This field of type B is at offset  (offset = 0 + bit_offset = 0) from our var of
type C

The first field of B is _vptr.B:

 <field_decl 0x40212450 _vptr.B
    type <pointer_type 0x401f005c
        type <pointer_type 0x401e5f74 __vtbl_ptr_type type <function_type
0x401e5f18>
            unsigned SI
            size <integer_cst 0x401693f0 constant invariant 32>
            unit size <integer_cst 0x40169180 constant invariant 4>
            align 32 symtab 0 alias set 7
            pointer_to_this <pointer_type 0x401f005c>>
        unsigned SI size <integer_cst 0x401693f0 32> unit size <integer_cst
0x40169180 4>
        align 32 symtab 0 alias set 4>
    unsigned virtual SI file /home/dberlin/22488.cc line 15 size <integer_cst
0x401693f0 32> unit size <integer_cst 0x40169180 4>
    align 32 offset_align 128
    offset <integer_cst 0x40169198 type <integer_type 0x4017b000 unsigned int>
constant invariant 0>
    bit offset <integer_cst 0x40169960 type <integer_type 0x4017b05c
bit_size_type> constant invariant 0> context <record_type 0x40212170 B> chain
<type_decl 0x401eec98 B>>

It is at offset 0 from our field of type B, which is at offset 0 from our var of
type C.

The next field after B is a type_decl.
The next field after the type_decl is field_decl 0x40212564 D.1781

<field_decl 0x40212564 D.1781
    type <record_type 0x4020e9b4 A addressable tree_2 needs-constructing type_1
type_4 type_5 BLK
        size <integer_cst 0x40169a80 constant invariant 96>
        unit size <integer_cst 0x40169a98 constant invariant 12>
        align 32 symtab 0 alias set 3
        fields <field_decl 0x4020ee04 _vptr.A type <pointer_type 0x401f005c>
            unsigned virtual SI file /home/dberlin/22488.cc line 8
            size <integer_cst 0x401693f0 constant invariant 32>
            unit size <integer_cst 0x40169180 constant invariant 4>
            align 32 offset_align 128
            offset <integer_cst 0x40169198 constant invariant 0>
            bit offset <integer_cst 0x40169960 constant invariant 0> context
<record_type 0x4020e9b4 A> chain <field_decl 0x4020ea10 i>>
       needs-constructor needs-destructor X() X(constX&) this=(X&) n_parents=0
use_template=0 interface-only
        pointer_to_this <pointer_type 0x4020ebdc> chain <type_decl 0x401eea90 A>>
    ignored decl_6 BLK file /home/dberlin/22488.cc line 15
    size <integer_cst 0x40210630 type <integer_type 0x4017b05c bit_size_type>
constant invariant 80>
    unit size <integer_cst 0x40210678 type <integer_type 0x4017b000 unsigned
int> constant invariant 10>
    align 32 offset_align 128 offset <integer_cst 0x40169198 0> bit offset
<integer_cst 0x401693f0 32> context <record_type 0x40212170 B>>

It is at offset 32 from our field of type B, which is at offset 0 from our var
of type C. So total offset = 32 for this field.
It is of type A.

The first field of type A is _vptr.A.



<field_decl 0x4020ee04 _vptr.A
    type <pointer_type 0x401f005c
        type <pointer_type 0x401e5f74 __vtbl_ptr_type type <function_type
0x401e5f18>
            unsigned SI
            size <integer_cst 0x401693f0 constant invariant 32>
            unit size <integer_cst 0x40169180 constant invariant 4>
            align 32 symtab 0 alias set 7
            pointer_to_this <pointer_type 0x401f005c>>
        unsigned SI size <integer_cst 0x401693f0 32> unit size <integer_cst
0x40169180 4>
        align 32 symtab 0 alias set 4>
    unsigned virtual SI file /home/dberlin/22488.cc line 8 size <integer_cst
0x401693f0 32> unit size <integer_cst 0x40169180 4>
    align 32 offset_align 128
    offset <integer_cst 0x40169198 type <integer_type 0x4017b000 unsigned int>
constant invariant 0>
    bit offset <integer_cst 0x40169960 type <integer_type 0x4017b05c
bit_size_type> constant invariant 0> context <record_type 0x4020e9b4 A> chain
<field_decl 0x4020ea10 i>>

This field is at offset 0 from our field of type A, which is at offset 32 from
our field of type B, which is at offset 0 from our var of type C. So total
offset = 32 from var C for this field.

Let's skip the rest of the fields of our field of type A since they don't mtater
for showing the overlap.
Pop back up to the field of type B, then pop back up to our original var of type C.

The next *field* of type C is 
 <field_decl 0x40212b24 x
    type <record_type 0x4020e844 X type_1 type_5 BLK
        size <integer_cst 0x40169a80 constant invariant 96>
        unit size <integer_cst 0x40169a98 constant invariant 12>
        align 32 symtab 0 alias set 22
        fields <field_decl 0x4020e8a0 i0 type <integer_type 0x4017b284 int>
            nonlocal decl_3 SI file /home/dberlin/22488.cc line 3
            size <integer_cst 0x401693f0 constant invariant 32>
            unit size <integer_cst 0x40169180 constant invariant 4>
            align 32 offset_align 128
            offset <integer_cst 0x40169198 constant invariant 0>
            bit offset <integer_cst 0x40169960 constant invariant 0> context
<record_type 0x4020e844 X> chain <field_decl 0x4020e8fc i1>>
        X() X(constX&) this=(X&) n_parents=0 use_template=0 interface-unknown
        pointer_to_this <pointer_type 0x402164ac> reference_to_this
<reference_type 0x4021633c> chain <type_decl 0x401ee958 X>>
    used nonlocal decl_3 BLK file /home/dberlin/22488.cc line 19 size
<integer_cst 0x40169a80 96> unit size <integer_cst 0x40169a98 12>
    align 32 offset_align 128 offset <integer_cst 0x40169198 0> bit offset
<integer_cst 0x401693f0 32> context <record_type 0x40212ac8 C> chain <type_decl
0x401eee38 C>>


This says that we have a field decl named x of type X at offset 32 from our var
of type C.
It's first field  is i0:
<field_decl 0x4020e8a0 i0
    type <integer_type 0x4017b284 int public SI
        size <integer_cst 0x401693f0 constant invariant 32>
        unit size <integer_cst 0x40169180 constant invariant 4>
        align 32 symtab 0 alias set 5 precision 32 min <integer_cst 0x401693a8
-2147483648> max <integer_cst 0x401693c0 2147483647>
        pointer_to_this <pointer_type 0x4017bc38>>
    nonlocal decl_3 SI file /home/dberlin/22488.cc line 3 size <integer_cst
0x401693f0 32> unit size <integer_cst 0x40169180 4>
    align 32 offset_align 128
    offset <integer_cst 0x40169198 type <integer_type 0x4017b000 unsigned int>
constant invariant 0>
    bit offset <integer_cst 0x40169960 type <integer_type 0x4017b05c
bit_size_type> constant invariant 0> context <record_type 0x4020e844 X> chain
<field_decl 0x4020e8fc i1>>

This field is at offset 0 from our var of field of type X which is at offset 32
from our var of type C.

Thus, it overlaps with _vptr.A.
Does your frontend output look like this?

Are we expected to be adding the deepest offset from the first depth first
search to the following ones when we pop back up or something?

If so, the docs should be clarified so they state "structure type" instead of
"structure", since i consider the *structure* here to be the variable (as would,
i argue, anyone who programs instead of works on type systems :P), in which
case, the offsets are wrong.


/* In a FIELD_DECL, this is the field position, counting in bytes, of the
   byte containing the bit closest to the beginning of the structure.  */
#define DECL_FIELD_OFFSET(NODE) (FIELD_DECL_CHECK (NODE)->field_decl.offset)

/* In a FIELD_DECL, this is the offset, in bits, of the first bit of the
   field from DECL_FIELD_OFFSET.  */
#define DECL_FIELD_BIT_OFFSET(NODE) (FIELD_DECL_CHECK (NODE)->field_decl.bit_offset)



-- 


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


  parent reply	other threads:[~2005-09-27 20:42 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-14 14:16 [Bug tree-optimization/22488] New: ICE: in first_vi_for_offset, at tree-ssa-structalias.c:2585 with -O3 micis at gmx dot de
2005-07-14 14:17 ` [Bug tree-optimization/22488] " micis at gmx dot de
2005-07-14 14:22 ` [Bug tree-optimization/22488] [4.1 Regression] " pinskia at gcc dot gnu dot org
2005-07-14 14:35 ` micis at gmx dot de
2005-07-14 14:46 ` micis at gmx dot de
2005-07-14 14:57 ` dberlin at gcc dot gnu dot org
2005-07-14 15:00 ` micis at gmx dot de
2005-07-14 15:14 ` dberlin at dberlin dot org
2005-07-14 16:57 ` reichelt at gcc dot gnu dot org
2005-07-14 17:55 ` dberlin at dberlin dot org
2005-07-14 20:25 ` reichelt at gcc dot gnu dot org
2005-07-14 20:40 ` pinskia at gcc dot gnu dot org
2005-07-23 17:54 ` dberlin at gcc dot gnu dot org
2005-07-26 13:21 ` rguenth at gcc dot gnu dot org
2005-08-06  6:53 ` [Bug c++/22488] " pinskia at gcc dot gnu dot org
2005-08-29 12:13 ` micis at gmx dot de
2005-08-29 12:15 ` rguenth at gcc dot gnu dot org
2005-08-29 13:57 ` dberlin at dberlin dot org
2005-08-29 14:08 ` [Bug c++/22488] [4.1 Regression] C++ generates incorrect overlapping fields dberlin at gcc dot gnu dot org
2005-09-05 14:19 ` pinskia at gcc dot gnu dot org
2005-09-05 14:20 ` pinskia at gcc dot gnu dot org
2005-09-18 15:39 ` rguenth at gcc dot gnu dot org
2005-09-18 16:29 ` mmitchel at gcc dot gnu dot org
2005-09-27 17:57 ` mmitchel at gcc dot gnu dot org
2005-09-27 20:42 ` dberlin at gcc dot gnu dot org [this message]
2005-09-27 21:13 ` mark at codesourcery dot com
2005-09-28  2:03 ` dberlin at gcc dot gnu dot org
2005-09-28  2:06 ` mark at codesourcery dot com
2005-09-28  2:32 ` dberlin at dberlin dot org
2005-09-28  2:34 ` pinskia at gcc dot gnu dot org
2005-09-28 15:57 ` [Bug tree-optimization/22488] [4.1 Regression] push_fields_onto_fieldstack calculates offset incorrectly mmitchel at gcc dot gnu dot org
2005-09-28 19:39 ` jason at redhat dot com
2005-09-28 20:16 ` dberlin at dberlin dot org
2005-09-28 20:29 ` mark at codesourcery dot com
2005-09-28 20:34 ` dberlin at dberlin dot org
2005-09-28 20:40 ` mark at codesourcery dot com
2005-09-29 17:20 ` jason at redhat dot com
2005-09-29 18:20 ` mark at codesourcery dot com

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050927204252.7956.qmail@sourceware.org \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).