This is the mail archive of the gcc-bugs@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]

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


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78839

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jason at gcc dot gnu.org,
                   |                            |pmderodat at gcc dot gnu.org

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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).

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