[Bug debug/111409] Invalid .debug_macro.dwo macro information for split DWARF

[osandov at osandov dot com via Gcc-bugs]

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

Omar Sandoval  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #4 from Omar Sandoval  ---
Thanks for the test fix. I believe this is now resolved.

[Bug debug/111409] Invalid .debug_macro.dwo macro information for split DWARF

[osandov at osandov dot com via Gcc-bugs]

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

--- Comment #1 from Omar Sandoval  ---
Patch sent:
https://gcc.gnu.org/pipermail/gcc-patches/2023-September/630242.html

[Bug debug/111409] New: Invalid .debug_macro.dwo macro information for split DWARF

[osandov at osandov dot com via Gcc-bugs]

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

Bug ID: 111409
   Summary: Invalid .debug_macro.dwo macro information for split
DWARF
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: osandov at osandov dot com
  Target Milestone: ---

When using -g3 -gsplit-dwarf, the generated macro information has a couple of
issues.

I'm using the following trivial source file:

$ cat test.c
#define ZERO 0
int main(void)
{
return ZERO;
}

First, GCC emits DW_MACRO_import entries, but they always have an offset of 0:

$ gcc -g3 -gsplit-dwarf test.c
$ readelf --debug-dump=macro a-test.dwo | head -n 14
Contents of the .debug_macro.dwo section:

  Offset:  0x0
  Version: 5
  Offset size: 4
  Offset into .debug_line: 0x0

 DW_MACRO_import - offset : 0x0
 DW_MACRO_start_file - lineno: 0 filenum: 1
 DW_MACRO_start_file - lineno: 0 filenum: 2
 DW_MACRO_import - offset : 0x0
 DW_MACRO_end_file
 DW_MACRO_define_strx lineno : 1 macro : 
 DW_MACRO_end_file

Second, each macro unit is in its own .debug_macro.dwo section:

$ readelf -S -W a-test.dwo | grep -F .debug_macro
  [ 3] .debug_macro.dwo  PROGBITS b2 1e 00   E 
0   0  1
  [ 4] .debug_macro.dwo  PROGBITS d0 00059e 00 
0   0  1
  [ 5] .debug_macro.dwo  PROGBITS 00066e 1b 00 
0   0  1

As far as I can tell, the DWARF specification doesn't allow this, and tools
seem to only use either the first or last section (gdb only finds the first
one, and dwp only copies the last one into the .dwp file).

These seem to have the same underlying cause: when not using split DWARF, the
linker deduplicates units and relocates the import offsets appropriately, but
this is not possible with split DWARF. I imagine that the fix would be to not
use imports for split DWARF and only generate one macro unit per .dwo file
containing everything.

(P.S., -g3 -gdwarf-4 -gstrict-dwarf -gsplit-dwarf generates a valid
.debug_macinfo.dwo because it doesn't have a notion of imports.)

[Bug c/97225] New: Failure to optimize out conditional addition of zero

[osandov at osandov dot com via Gcc-bugs]

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

Bug ID: 97225
   Summary: Failure to optimize out conditional addition of zero
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: osandov at osandov dot com
  Target Milestone: ---

For the following code:

#include 

struct vector {
int *data;
size_t size;
};

int *vector_end(struct vector *vec)
{
return vec->data + vec->size;
}

GCC 10.2.0 on x86-64 generates the following code (same on -O2, -O3, and -Os):

vector_end:
movq8(%rdi), %rdx
movq(%rdi), %rax
leaq(%rax,%rdx,4), %rax
ret

However, vector_end() needs to handle empty vectors represented as { NULL, 0 }.
Pointer arithmetic on a null pointer is undefined behavior (even NULL + 0, as
far as I can tell from the C standard), so the correct code is:

int *vector_end(struct vector *vec)
{
if (vec->size == 0)
return vec->data;
return vec->data + vec->size;
}

I'd expect this to generate the same code, but GCC 10.2.0 generates a
conditional move with -O2 and -O3:

vector_end:
movq8(%rdi), %rdx
movq(%rdi), %rax
testq   %rdx, %rdx
leaq(%rax,%rdx,4), %rcx
cmovne  %rcx, %rax
ret

And a branch with -Os:

vector_end:
movq8(%rdi), %rdx
movq(%rdi), %rax
testq   %rdx, %rdx
je  .L1
leaq(%rax,%rdx,4), %rax
.L1:
ret

Clang 10.0.1, on the other hand, generates the same code with and without the
size check (oddly enough, it also falls back to a conditional move if the size
member is an int or unsigned int instead of size_t/unsigned long):

vector_end: # @vector_end
movq8(%rdi), %rax
shlq$2, %rax
addq(%rdi), %rax
retq

Can GCC avoid the conditional move/branch here?