This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]
Other format:	[Raw text]

Re: representation of struct field offsets

From: Mark Mitchell <mark at codesourcery dot com>
To: Richard Kenner <kenner at vlsi1 dot ultra dot nyu dot edu>
Cc: clattner at apple dot com, dberlin at dberlin dot org, gcc at gcc dot gnu dot org, sandra at codesourcery dot com
Date: Sun, 01 Oct 2006 10:40:50 -0700
Subject: Re: representation of struct field offsets
References: <451B2DA5.8070504@codesourcery.com> <451C33F8.6090900@codesourcery.com> <D9F9CDE8-279E-44EE-AB11-EC4C00994042@apple.com> <10609290211.AA20506@vlsi1.ultra.nyu.edu> <4aca3dc20609290654y3f3bca8br3e31d094af824080@mail.gmail.com> <10609292224.AA05432@vlsi1.ultra.nyu.edu> <451DC110.5010107@codesourcery.com> <10609301225.AA14348@vlsi1.ultra.nyu.edu>

Richard Kenner wrote:

That doesn't explain why the bit value isn't normalized to be smaller than BITS_PER_UNIT; any whole bytes could be incorporated into the variably sized offset.
It can't be normalized to BITS_PER_UNIT, but to DECL_OFFSET_ALIGN since
we are asserting that DECL_FIELD_OFFSET is aligned to DECL_OFFSET_ALIGN.

That doesn't make sense to me. It seems to me that we can normalize it however we please; ultimately, all these representations just give us a way of computing the first bit of the field. We presently choose to normalize to DECL_OFFSET_ALIGN, but we could just as well choose to normalize to BITS_PER_UNIT. So long as we can compute the starting offset of the field, why does it matter what the normalization constant is?

--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Follow-Ups:
- Re: representation of struct field offsets
  - From: Richard Kenner

Index Nav:	[Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav:	[Date Prev] [Date Next]	[Thread Prev] [Thread Next]