[Bug debug/71668] New: certain bitfields get negative DW_AT_bit_offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71668 Bug ID: 71668 Summary: certain bitfields get negative DW_AT_bit_offset Product: gcc Version: 5.3.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: richlowe at richlowe dot net Target Milestone: --- Created attachment 38770 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38770=edit test case source The DWARF for certain structures, at least when using -gdwarf-2, seems to emit with a signed, negative, bitoffset. I'm not sure whether that's valid, but it's causing some of our tools to choke and since it seems to happen in such a narrow range of circumstances it seems to be, at the least, suspicious. The DWARF standards seem to have little to say on the matter. It appears to happen when a bitfield structure is between 33 and 39 bits in size, and at no other time I've been able to determine (a large source tree contains only a single instance of the problem, from which this test case was reduced). Perhaps something is off-by-one on the number of bytes somewhere? My apologies if this behaviour is correct. I'm attaching a test file, the following diff shows the dwarfdump between a good and bad sized version of the bitfield: --- good.dwarf 2016-06-26 18:40:52.582216186 +0100 +++ bad.dwarf 2016-06-26 18:41:09.862679856 +0100 @@ -23,8 +23,8 @@ DW_AT_decl_line 0x0004 DW_AT_type <0x0050> DW_AT_byte_size 0x0004 -DW_AT_bit_size 0x0008 -DW_AT_bit_offset0x0018 +DW_AT_bit_size 0x0007 +DW_AT_bit_offset0x0019 DW_AT_data_member_location DW_OP_plus_uconst 0 < 2><0x003e> DW_TAG_member DW_AT_name "csts_cfs" @@ -33,8 +33,8 @@ DW_AT_type <0x0050> DW_AT_byte_size 0x0004 DW_AT_bit_size 0x0020 -DW_AT_bit_offset0x -DW_AT_data_member_location DW_OP_plus_uconst 1 +DW_AT_bit_offset0xfff9 +DW_AT_data_member_location DW_OP_plus_uconst 0 < 1><0x0050>DW_TAG_base_type DW_AT_byte_size 0x0004 DW_AT_encoding DW_ATE_unsigned
[Bug driver/69451] want a high-level option to disable optimizations that harm debuggability
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69451 --- Comment #2 from Rich Lowe --- I'm not certain -Og exactly matches what I wanted, though it's close. I was hoping to maintain the existing -O I was specifying, but have those problematic optimizations disabled en-masse. Does -Og allow for that? (such that I would pass -O3 -Og, and get in effect -O3 -fno-ipa-cp -fno-ipa-icf etc.)
[Bug driver/69451] New: want a high-level option to disable optimizations that harm debuggability
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69451 Bug ID: 69451 Summary: want a high-level option to disable optimizations that harm debuggability Product: gcc Version: 5.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: richlowe at richlowe dot net CC: alan.coopersmith at oracle dot com Target Milestone: --- There are several optimization passes in the compiler which make debugging, tracing, and the like, unnecessarily cumbersome. The big and obvious examples that spring to mind are optimizations that clone functions and Identical Code Folding (which does the opposite). Each makes tracing, placing breakpoints, etc, error prone and frustrating. A lot of optimization passes in question are indeed documented in this regard. It would be fantastic to have a high-level option which disabled optimizations which harm debugging in this way, so that users have a reliable way to do so without researching any optimization in each new release. I would suggest that any optimization which: - Changed the number or order of parameters - Passed parameters in a way other than defined by the relevant ABI - Cloned a function such that a logical function had more than one copy in text, with gensym'd names. - ICF'd a function such that a logical function had no copy in text, but was instead aliased to another Should be disabled by the desired flag.
[Bug bootstrap/53902] make install fails on SunOS 5.11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53902 Rich Lowe richlowe at richlowe dot net changed: What|Removed |Added CC||richlowe at richlowe dot net --- Comment #7 from Rich Lowe richlowe at richlowe dot net --- I'm pretty sure this is a result of using an older binutils. As best as I can tell, s11 shipped with 2.19, and s11u1 with 2.21. I know that 2.19 will fail in this manner, and that 2.22 appears to work. I have not personally tried 2.21
