[Bug debug/86582] [debug] vla size reported as 0 at Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86582 Allan Jensen changed: What|Removed |Added CC||linux at carewolf dot com --- Comment #3 from Allan Jensen --- Wouldn't this be solved by disable -ftree-dse for -Og where as bug 78685 is more complicated?
[Bug debug/86582] [debug] vla size reported as 0 at Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86582 Tom de Vries changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Tom de Vries --- If we change the f1 argument to 5, or we comment out the volatile asm in main, the problem is fixed, but for the test-case as is, we can't do anything more. At Os or O1, the problem doesn't occur, because a is optimized away after tree-dse eliminates the dead store (tree-dse also runs at Og, but doesn't manage to get rid of the dead store because ealias is not run for Og), and the body of the function f1 is very simple and doesn't overwrite the value of the argument i, so there's no need to reference back to the initial value of argument i in main. Contrary to what I thought initially, there's nothing vla specific here, this is a plain duplicate of PR78685. *** This bug has been marked as a duplicate of bug 78685 ***
[Bug debug/86582] [debug] vla size reported as 0 at Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86582
--- Comment #1 from Tom de Vries ---
(In reply to Tom de Vries from comment #0)
> By modifying main to return i, I get in addition:
> ...
> .uleb128 0x7# (DIE (0x77) DW_TAG_call_site_parameter)
> .uleb128 0x1# DW_AT_location
> .byte 0x55# DW_OP_reg5
> .uleb128 0x2# DW_AT_call_value
> .byte 0x73# DW_OP_breg3
> .sleb128 0
> ...
> and then gdb prints sizeof(a) as expected.
>
Which makes this test-case a duplicate of PR78685, and fkeep-vars-live would
help here.
> This seems to be cause DW_TAG_call_site_parameter is generated based on
> REG_CALL_ARG_LOCATION, and in the case without call_site_parameter we have:
> ...
> (call_insn 15 39 44 2 (set (reg:SI 0 ax)
> (call (mem:QI (symbol_ref:DI ("f1") [flags 0x3] 0x7f7bc3fc2700 f1>) \
> [0 f1 S1 A8])
> (const_int 0 [0]))) "vla-1.c":19 722 {*call_value}
> (expr_list:REG_CALL_ARG_LOCATION (nil)
> (expr_list:REG_DEAD (reg:SI 5 di)
> (expr_list:REG_EH_REGION (const_int 0 [0])
> (nil
> (expr_list:SI (use (reg:SI 5 di))
> (nil)))
> ...
> and in the case with call_site_parameter we have:
> ...
> (call_insn 15 14 17 2 (set (reg:SI 0 ax)
> (call (mem:QI (symbol_ref:DI ("f1") [flags 0x3] 0x7f701d65a700 f1>) \
> [0 f1 S1 A8])
> (const_int 0 [0]))) "vla-1.c":19 722 {*call_value}
> (expr_list:REG_CALL_ARG_LOCATION (expr_list:REG_DEP_TRUE (concat:SI
> (reg:SI 5 di)
> (reg:SI 3 bx [orig:89 i ] [89]))
> (nil))
> (expr_list:REG_DEAD (reg:SI 5 di)
> (expr_list:REG_EH_REGION (const_int 0 [0])
> (nil
> (expr_list:SI (use (reg:SI 5 di))
> (nil)))
> ...
>
> So, why doesn't var-tracking generate the REG_CALL_ARG_LOCATION that we need?
Because the register containing the arg is not guaranteed to be live across the
call:
...
.LVL7:
# DEBUG i => 0x5
#
/home/vries/gcc_versions/devel/src/gcc/testsuite/gcc.dg/guality/vla-1.c:18:3
.loc 1 18 3
movl$5, %edi
.LVL8:
# DEBUG i RESET
# DEBUG i => di
#
/home/vries/gcc_versions/devel/src/gcc/testsuite/gcc.dg/guality/vla-1.c:19:3
.loc 1 19 3
#
/home/vries/gcc_versions/devel/src/gcc/testsuite/gcc.dg/guality/vla-1.c:19:7
.loc 1 19 7 is_stmt 0
callf1
.LVL9:
# DEBUG i RESET
...
If we modify main to return i, we have instead:
...
.LVL7:
# DEBUG i => 0x5
#
/home/vries/gcc_versions/devel/src/gcc/testsuite/gcc.dg/guality/vla-1.c:18:3
.loc 1 18 3
movl$5, %ebx
.LVL8:
# DEBUG i RESET
# DEBUG i => bx
#
/home/vries/gcc_versions/devel/src/gcc/testsuite/gcc.dg/guality/vla-1.c:19:3
.loc 1 19 3
#
/home/vries/gcc_versions/devel/src/gcc/testsuite/gcc.dg/guality/vla-1.c:19:7
.loc 1 19 7 is_stmt 0
movl%ebx, %edi
callf1
.LVL9:
...
