[Bug debug/106718] New: Behavior does not follow the standard for DW_AT_ranges and DW_FORM_sec_offset

[navidr at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 106718
   Summary: Behavior does not follow the standard for DW_AT_ranges
and DW_FORM_sec_offset
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: navidr at gcc dot gnu.org
  Target Milestone: ---

gcc-trunk sort.c -O3 -gdwarf-5 -gsplit-dwarf -g3 -o sort

.
.
.
36> DW_TAG_inlined_subroutine
DW_AT_abstract_origin   DW_FORM_ref4
DW_AT_entry_pc  DW_FORM_addrx
DW_FORM_data1
DW_AT_rangesDW_FORM_rnglistx
.
.
.

DWARF5 standard explicitly mentions that you should not use "DW_FORM_rnglistx"
form when your header does have offset_entry_count=0.  

"If the offset_entry_count is zero, then DW_FORM_rnglistx cannot be used to
access a range list; DW_FORM_sec_offset must be used instead. If the
offset_entry_count is non-zero, then DW_FORM_rnglistx may be used to access a
range list; this is necessary in split units and may be more compact than using
DW_FORM_sec_offsetin non-split units. (Page 242, DWARF5 Specification
document)."


I didn't try to bisect to find exact commit, but I didn't have this problem 1
year ago. 


#include 
#include 
#include 
#define ARRAY_LEN 5

static struct timeval tm1;

static inline void start() {
gettimeofday(&tm1, NULL);
}

static inline void stop() {
struct timeval tm2;
gettimeofday(&tm2, NULL);
unsigned long long t = 1000 * (tm2.tv_sec - tm1.tv_sec) +\
   (tm2.tv_usec - tm1.tv_usec) / 1000;
printf("%llu ms\n", t);
}

void bubble_sort (int *a, int n) {
int i, t, s = 1;
while (s) {
s = 0;
for (i = 1; i < n; i++) {
if (a[i] < a[i - 1]) {
t = a[i];
a[i] = a[i - 1];
a[i - 1] = t;
s = 1;
}
}
}
}

void sort_array() {
printf("Bubble sorting array of %d elements\n", ARRAY_LEN);
int data[ARRAY_LEN], i;
for(i=0; i

[Bug debug/106718] GCC does not follow DWARF5 standard for DW_AT_ranges and DW_FORM_rnglistx

[navidr at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Navid Rahimi  ---
Thanks for clarifying it. I was able to fix a bug somewhere else with your
explanation.

[Bug debug/106718] GCC does not follow DWARF5 standard for DW_AT_ranges and DW_FORM_rnglistx

[navidr at gcc dot gnu.org via Gcc-bugs]

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

Navid Rahimi  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|UNCONFIRMED |RESOLVED

--- Comment #3 from Navid Rahimi  ---
Status change to Invalid report.

[Bug tree-optimization/103514] Missing XOR-EQ-AND Optimization

[navidr at gcc dot gnu.org via Gcc-bugs]

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

Navid Rahimi  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Navid Rahimi  ---
Thanks Jeff.

[Bug tree-optimization/103536] New: Suboptimal codegen for && and || combination.

[navidr at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 103536
   Summary: Suboptimal codegen for && and || combination.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: navidr at gcc dot gnu.org
  Target Milestone: ---

We do have suboptimal codegen for this pattern:

https://compiler-explorer.com/z/dszaK49WT

bool
src_1 (bool a, bool b)
{
return (a || b) && (a && b);
}

bool
src_2 (bool a, bool b) // no problem here
{
return (a && b) && (a || b);
}

bool
tgt (bool a, bool b) // what we want
{
return (a && b);
}


In the case of src_2, it is the "ethread" pass which will remove the extra
basicblock. But in case of src_1 since the operation is spread over multiple
basicblocks, the match.pd is not able to detect and solve this.

1) In limited situations, it is possible to detect pattern in GENERIC and fix
this:

As proof of concept, I tried with something like this and was able to fix this
in GENERIC:
(for firstAnd (truth_and truth_andif)
 (for secondAnd (truth_and truth_andif)
  (for firstOr (truth_or truth_orif)
   (simplify
(firstAnd (firstOr @0 @1) (secondAnd truth_valued_p@0 truth_valued_p@1))
(truth_and @0 @1)

Because of GENERIC limitation, this is not going to work on something like
this:
bool src_12 (bool a, bool b)
{
int z = a || b;
return z && (a && b);
}



2) A better approach which I haven't looked at, is not to spread this over
multiple basic blocks.