GCC Bugzilla – Attachment 20733 Details for
Bug 41048
bad DW_AT_data_member_location from g++
Home
|
New
|
Browse
|
Search
|
[?]
|
Reports
|
Help
|
New Account
|
Log In
Remember
[x]
|
Forgot Password
Login:
[x]
[patch]
gcc46-pr41048.patch
gcc46-pr41048.patch (text/plain), 11.10 KB, created by
Jakub Jelinek
on 2010-05-24 11:13:01 UTC
(
hide
)
Description:
gcc46-pr41048.patch
Filename:
MIME Type:
Creator:
Jakub Jelinek
Created:
2010-05-24 11:13:01 UTC
Size:
11.10 KB
patch
obsolete
>2010-05-24 Jakub Jelinek <jakub@redhat.com> > > PR debug/41048 > * dwarf2out.c (double_int_type_size_in_bits): New function. > (round_up_to_align): Change first argument and return value to > double_int. > (field_byte_offset): Work internally on double_ints. > >--- gcc/dwarf2out.c.jj 2010-05-21 17:32:55.000000000 +0200 >+++ gcc/dwarf2out.c 2010-05-24 13:01:20.000000000 +0200 >@@ -12358,6 +12358,21 @@ simple_type_size_in_bits (const_tree typ > return TYPE_ALIGN (type); > } > >+/* Similarly, but return a double_int instead of UHWI. */ >+ >+static inline double_int >+double_int_type_size_in_bits (const_tree type) >+{ >+ if (TREE_CODE (type) == ERROR_MARK) >+ return uhwi_to_double_int (BITS_PER_WORD); >+ else if (TYPE_SIZE (type) == NULL_TREE) >+ return double_int_zero; >+ else if (TREE_CODE (TYPE_SIZE (type)) == INTEGER_CST) >+ return tree_to_double_int (TYPE_SIZE (type)); >+ else >+ return uhwi_to_double_int (TYPE_ALIGN (type)); >+} >+ > /* Given a pointer to a tree node for a subrange type, return a pointer > to a DIE that describes the given type. */ > >@@ -15408,20 +15423,15 @@ simple_decl_align_in_bits (const_tree de > > /* Return the result of rounding T up to ALIGN. */ > >-static inline HOST_WIDE_INT >-round_up_to_align (HOST_WIDE_INT t, unsigned int align) >+static inline double_int >+round_up_to_align (double_int t, unsigned int align) > { >- /* We must be careful if T is negative because HOST_WIDE_INT can be >- either "above" or "below" unsigned int as per the C promotion >- rules, depending on the host, thus making the signedness of the >- direct multiplication and division unpredictable. */ >- unsigned HOST_WIDE_INT u = (unsigned HOST_WIDE_INT) t; >- >- u += align - 1; >- u /= align; >- u *= align; >- >- return (HOST_WIDE_INT) u; >+ double_int alignd = uhwi_to_double_int (align); >+ t = double_int_add (t, alignd); >+ t = double_int_add (t, double_int_minus_one); >+ t = double_int_div (t, alignd, true, TRUNC_DIV_EXPR); >+ t = double_int_mul (t, alignd); >+ return t; > } > > /* Given a pointer to a FIELD_DECL, compute and return the byte offset of the >@@ -15434,8 +15444,9 @@ round_up_to_align (HOST_WIDE_INT t, unsi > static HOST_WIDE_INT > field_byte_offset (const_tree decl) > { >- HOST_WIDE_INT object_offset_in_bits; >- HOST_WIDE_INT bitpos_int; >+ double_int object_offset_in_bits; >+ double_int object_offset_in_bytes; >+ double_int bitpos_int; > > if (TREE_CODE (decl) == ERROR_MARK) > return 0; >@@ -15445,24 +15456,24 @@ field_byte_offset (const_tree decl) > /* We cannot yet cope with fields whose positions are variable, so > for now, when we see such things, we simply return 0. Someday, we may > be able to handle such cases, but it will be damn difficult. */ >- if (! host_integerp (bit_position (decl), 0)) >+ if (TREE_CODE (bit_position (decl)) != INTEGER_CST) > return 0; > >- bitpos_int = int_bit_position (decl); >+ bitpos_int = tree_to_double_int (bit_position (decl)); > > #ifdef PCC_BITFIELD_TYPE_MATTERS > if (PCC_BITFIELD_TYPE_MATTERS) > { > tree type; > tree field_size_tree; >- HOST_WIDE_INT deepest_bitpos; >- unsigned HOST_WIDE_INT field_size_in_bits; >+ double_int deepest_bitpos; >+ double_int field_size_in_bits; > unsigned int type_align_in_bits; > unsigned int decl_align_in_bits; >- unsigned HOST_WIDE_INT type_size_in_bits; >+ double_int type_size_in_bits; > > type = field_type (decl); >- type_size_in_bits = simple_type_size_in_bits (type); >+ type_size_in_bits = double_int_type_size_in_bits (type); > type_align_in_bits = simple_type_align_in_bits (type); > > field_size_tree = DECL_SIZE (decl); >@@ -15473,85 +15484,92 @@ field_byte_offset (const_tree decl) > field_size_tree = bitsize_zero_node; > > /* If the size of the field is not constant, use the type size. */ >- if (host_integerp (field_size_tree, 1)) >- field_size_in_bits = tree_low_cst (field_size_tree, 1); >+ if (TREE_CODE (field_size_tree) == INTEGER_CST) >+ field_size_in_bits = tree_to_double_int (field_size_tree); > else >- field_size_in_bits = type_size_in_bits; >+ field_size_in_bits = type_size_in_bits; > > decl_align_in_bits = simple_decl_align_in_bits (decl); > > /* The GCC front-end doesn't make any attempt to keep track of the >- starting bit offset (relative to the start of the containing >- structure type) of the hypothetical "containing object" for a >- bit-field. Thus, when computing the byte offset value for the >- start of the "containing object" of a bit-field, we must deduce >- this information on our own. This can be rather tricky to do in >- some cases. For example, handling the following structure type >- definition when compiling for an i386/i486 target (which only >- aligns long long's to 32-bit boundaries) can be very tricky: >+ starting bit offset (relative to the start of the containing >+ structure type) of the hypothetical "containing object" for a >+ bit-field. Thus, when computing the byte offset value for the >+ start of the "containing object" of a bit-field, we must deduce >+ this information on our own. This can be rather tricky to do in >+ some cases. For example, handling the following structure type >+ definition when compiling for an i386/i486 target (which only >+ aligns long long's to 32-bit boundaries) can be very tricky: > > struct S { int field1; long long field2:31; }; > >- Fortunately, there is a simple rule-of-thumb which can be used >- in such cases. When compiling for an i386/i486, GCC will >- allocate 8 bytes for the structure shown above. It decides to >- do this based upon one simple rule for bit-field allocation. >- GCC allocates each "containing object" for each bit-field at >- the first (i.e. lowest addressed) legitimate alignment boundary >- (based upon the required minimum alignment for the declared >- type of the field) which it can possibly use, subject to the >- condition that there is still enough available space remaining >- in the containing object (when allocated at the selected point) >- to fully accommodate all of the bits of the bit-field itself. >- >- This simple rule makes it obvious why GCC allocates 8 bytes for >- each object of the structure type shown above. When looking >- for a place to allocate the "containing object" for `field2', >- the compiler simply tries to allocate a 64-bit "containing >- object" at each successive 32-bit boundary (starting at zero) >- until it finds a place to allocate that 64- bit field such that >- at least 31 contiguous (and previously unallocated) bits remain >- within that selected 64 bit field. (As it turns out, for the >- example above, the compiler finds it is OK to allocate the >- "containing object" 64-bit field at bit-offset zero within the >- structure type.) >- >- Here we attempt to work backwards from the limited set of facts >- we're given, and we try to deduce from those facts, where GCC >- must have believed that the containing object started (within >- the structure type). The value we deduce is then used (by the >- callers of this routine) to generate DW_AT_location and >- DW_AT_bit_offset attributes for fields (both bit-fields and, in >- the case of DW_AT_location, regular fields as well). */ >+ Fortunately, there is a simple rule-of-thumb which can be used >+ in such cases. When compiling for an i386/i486, GCC will >+ allocate 8 bytes for the structure shown above. It decides to >+ do this based upon one simple rule for bit-field allocation. >+ GCC allocates each "containing object" for each bit-field at >+ the first (i.e. lowest addressed) legitimate alignment boundary >+ (based upon the required minimum alignment for the declared >+ type of the field) which it can possibly use, subject to the >+ condition that there is still enough available space remaining >+ in the containing object (when allocated at the selected point) >+ to fully accommodate all of the bits of the bit-field itself. >+ >+ This simple rule makes it obvious why GCC allocates 8 bytes for >+ each object of the structure type shown above. When looking >+ for a place to allocate the "containing object" for `field2', >+ the compiler simply tries to allocate a 64-bit "containing >+ object" at each successive 32-bit boundary (starting at zero) >+ until it finds a place to allocate that 64- bit field such that >+ at least 31 contiguous (and previously unallocated) bits remain >+ within that selected 64 bit field. (As it turns out, for the >+ example above, the compiler finds it is OK to allocate the >+ "containing object" 64-bit field at bit-offset zero within the >+ structure type.) >+ >+ Here we attempt to work backwards from the limited set of facts >+ we're given, and we try to deduce from those facts, where GCC >+ must have believed that the containing object started (within >+ the structure type). The value we deduce is then used (by the >+ callers of this routine) to generate DW_AT_location and >+ DW_AT_bit_offset attributes for fields (both bit-fields and, in >+ the case of DW_AT_location, regular fields as well). */ > > /* Figure out the bit-distance from the start of the structure to >- the "deepest" bit of the bit-field. */ >- deepest_bitpos = bitpos_int + field_size_in_bits; >+ the "deepest" bit of the bit-field. */ >+ deepest_bitpos = double_int_add (bitpos_int, field_size_in_bits); > > /* This is the tricky part. Use some fancy footwork to deduce >- where the lowest addressed bit of the containing object must >- be. */ >- object_offset_in_bits = deepest_bitpos - type_size_in_bits; >+ where the lowest addressed bit of the containing object must >+ be. */ >+ object_offset_in_bits >+ = double_int_add (deepest_bitpos, double_int_neg (type_size_in_bits)); > > /* Round up to type_align by default. This works best for >- bitfields. */ >+ bitfields. */ > object_offset_in_bits >- = round_up_to_align (object_offset_in_bits, type_align_in_bits); >+ = round_up_to_align (object_offset_in_bits, type_align_in_bits); > >- if (object_offset_in_bits > bitpos_int) >- { >- object_offset_in_bits = deepest_bitpos - type_size_in_bits; >- >- /* Round up to decl_align instead. */ >- object_offset_in_bits >- = round_up_to_align (object_offset_in_bits, decl_align_in_bits); >- } >+ if (double_int_ucmp (object_offset_in_bits, bitpos_int) > 0) >+ { >+ object_offset_in_bits >+ = double_int_add (deepest_bitpos, >+ double_int_neg (type_size_in_bits)); >+ >+ /* Round up to decl_align instead. */ >+ object_offset_in_bits >+ = round_up_to_align (object_offset_in_bits, decl_align_in_bits); >+ } > } > else > #endif > object_offset_in_bits = bitpos_int; > >- return object_offset_in_bits / BITS_PER_UNIT; >+ object_offset_in_bytes >+ = double_int_div (object_offset_in_bits, >+ uhwi_to_double_int (BITS_PER_UNIT), true, >+ TRUNC_DIV_EXPR); >+ return double_int_to_shwi (object_offset_in_bytes); > } > > /* The following routines define various Dwarf attributes and any data
You cannot view the attachment while viewing its details because your browser does not support IFRAMEs.
View the attachment on a separate page
.
View Attachment As Diff
View Attachment As Raw
Actions:
View
|
Diff
Attachments on
bug 41048
: 20733