[Bug debug/78839] [6/7 Regression] DWARF output different between GCC 5 and 6

2017-01-17 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78839

--- Comment #12 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jan 17 18:32:13 2017
New Revision: 244545

URL: https://gcc.gnu.org/viewcvs?rev=244545=gcc=rev
Log:
PR debug/78839
* dwarf2out.c (field_byte_offset): Restore the
PCC_BITFIELD_TYPE_MATTERS behavior for INTEGER_CST DECL_FIELD_OFFSET
and DECL_FIELD_BIT_OFFSET.  Use fold_build2 instead of build2 + fold.
(analyze_variants_discr, gen_variant_part): Use fold_build2 instead
of build2 + fold.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c

[Bug debug/78839] [6/7 Regression] DWARF output different between GCC 5 and 6

2017-01-13 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78839

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug debug/78839] [6/7 Regression] DWARF output different between GCC 5 and 6

2017-01-11 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78839

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-01-11
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #11 from Jakub Jelinek  ---
Created attachment 40505
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40505=edit
gcc7-pr78839.patch

There were actually numerous bugs in that commit in the field_byte_offset
routine.  is_bit_offset_cst and is_byte_offset_cst vars were set to values that
is the opposite of their names, then the whole PCC_BITFIELD_TYPE_MATTERS block
was actually never entered, because there was:
  if (is_bit_offset_cst)
return NULL;

#ifdef PCC_BITFIELD_TYPE_MATTERS
  /* We used to handle only constant offsets in all cases.  Now, we handle
 properly dynamic byte offsets only when PCC bitfield type doesn't
 matter.  */
  if (PCC_BITFIELD_TYPE_MATTERS && is_byte_offset_cst && is_bit_offset_cst)

and after the first if is_bit_offset_cst thus was always false.  But even with
that fixed, the whole block computed something that has been just ignored.

So, let's fix this first, then as incremental separately tested patch also use
DECL_BIT_FIELD_REPRESENTATIVE if possible, and lastly for DWARF-4 and later we
actually shouldn't be emitting for bitfields DW_AT_data_member_location and
DW_AT_byte_size and DW_AT_bit_offset attributes at all, we should emit
DW_AT_data_bit_offset (PR71669) instead of those.  As GDB just gained
DW_AT_data_bit_offset support last November, I'll for now use it only for
-gdwarf-5 (which requires latest GDB anyway).

[Bug debug/78839] [6/7 Regression] DWARF output different between GCC 5 and 6

2016-12-20 Thread toconnor at forcepoint dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78839

--- Comment #10 from Tom O'Connor  ---
In regards to GDB, I noticed that when using a macro to get the offset for
these bitfields, with objects built by both GCC 5 and earlier as well as GCC 6,
I always get 0.  For example:

(gdb) macro define offsetof(t, f) &((t *) 0)->f)
(gdb) p offsetof(struct s, type)
$1 = (unsigned int *) 0x0

Historically, prior to GCC 6, this always matched up with DWARF's
DW_AT_data_member_location value for bitfields.  Yes, I see how GCC 6's
combination of data_member_location and bit_offset can be combined to reach the
true location.  Historically, my use case has used the data_member_location
value to get me the offset into say a raw memory image, for where to start
reading data from a field of a structure in memory; I'd do bitfield shifts
after reading from the aligned offset as reported in the DWARF structure.

If using DECL_BIT_FIELD_REPRESENTATIVE as data_member_location is nicer and
doesn't break the Ada use case, I'd be all for that.  But if what's currently
being emitted by GCC 6 is considered "more correct" than what previous versions
had emitted, then I'll have to adjust.  I only noticed the change between 5 and
6 once I started seeing odd results with the same code built by different GCCs.

[Bug debug/78839] [6/7 Regression] DWARF output different between GCC 5 and 6

2016-12-20 Thread derodat at adacore dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78839

Pierre-Marie de Rodat  changed:

   What|Removed |Added

 CC||derodat at adacore dot com

--- Comment #9 from Pierre-Marie de Rodat  ---
(In reply to Jakub Jelinek from comment #7)
> The behavior changed with r231762, I haven't looked (yet) into details if it
> is valid or not and why that changed.
I haven’t had a look yet neither… bit addressing is hard. ;-) All I can do for
now is to give some context for r231762: this commit tried to handle fields
with dynamic sizes/positions but only with a focus on the ones at least
byte-aligned.

My playground for this was discriminated types in Ada, and I’m not sure these
can be bit-packed (i.e. using sub-byte addressing). So if anything changed for
bitfields, that was not intentional and can likely be fixed as long as it does
not break things for the Ada types I tested. By the way, if one wants to see
what I used for testing, here it is:
https://github.com/pmderodat/dwarf-ada-testsuite/.

[Bug debug/78839] [6/7 Regression] DWARF output different between GCC 5 and 6

2016-12-19 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78839

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org,
   ||pmderodat at gcc dot gnu.org

--- Comment #8 from Jakub Jelinek  ---
So, first of all, it seems gdb handles this as expected no matter if it is the
debug info emitted by GCC 5 or 6+.  Say for protocol field,
data_member_location is either 0 and bit_offset 16, or data_member_location 1
and bit_offset 24 and the type is unsigned int in each case and little endian. 
So it is either bits 16-24 in unsigned int starting at offset 0, or bits 24-32
at unsigned int starting at offset 1, that is the same thing.  So the question
is why does it matter to you?
Though, I'd think it might be nicer to use byte_position of
DECL_BIT_FIELD_REPRESENTATIVE as data_member_location (so data_member_location
0 in this case).

[Bug debug/78839] [6/7 Regression] DWARF output different between GCC 5 and 6

2016-12-17 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78839

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org
  Component|other   |debug
   Target Milestone|--- |6.4
Summary|DWARF output different  |[6/7 Regression] DWARF
   |between GCC 5 and 6 |output different between
   ||GCC 5 and 6

--- Comment #7 from Jakub Jelinek  ---
The behavior changed with r231762, I haven't looked (yet) into details if it is
valid or not and why that changed.