Jakub,
On 01/11/2017 09:19 PM, Jakub Jelinek wrote:
In GCC 5 and earlier, field_byte_offset had code for
PCC_BITFIELD_TYPE_MATTERS target that figured out what
DW_AT_data_member_location value to use vs. DW_AT_bit_offset.
That code is still in there, but due to several bugs added in r231762
it never triggers anymore.
I totally plead guilty for this! When I originally patched this
function, something like 3 years ago, I had a hard time trying to
understand it (in retrospect, I probably failed that), tried various
things, had headaches while thinking about variable bit offsets, and
then IIRC saw no regression in GCC or GDB’s testsuite, so stopped
worrying and submitted my patch for review.
… anyway that’s it for the context. So thank you very much for working
on this!
The following patch fixes all this and restores the GCC 5 behavior.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
FWIW, this patch triggers no regression in my DWARF/Ada testsuite.
+ object_offset_in_bytes
+ = wi::lrshift (object_offset_in_bits, LOG2_BITS_PER_UNIT);
+ if (ctx->variant_part_offset == NULL_TREE)
+ {
+ *cst_offset = object_offset_in_bytes.to_shwi ();
+ return NULL;
+ }
+ tree_result = wide_int_to_tree (sizetype, object_offset_in_bytes);
I don’t understand this special case: IIUC, if this IF block was
missing, the flow would make this function return the same result thanks
to the similar IF block several lines below. Is it to avoid the
conversions to tree/wide int/HOST_WIDE_INT (i.e. an optimization)?
--
Pierre-Marie de Rodat
