On 07/05/2018 01:39 PM, Richard Biener wrote: > On Thu, Jul 5, 2018 at 1:25 PM Tom de Vries <tdevr...@suse.de> wrote: >> >> [ was: Re: [testsuite/guality, committed] Prevent optimization of local in >> vla-1.c ] >> >> On Wed, Jul 04, 2018 at 02:32:27PM +0200, Tom de Vries wrote: >>> On 07/03/2018 11:05 AM, Tom de Vries wrote: >>>> On 07/02/2018 10:16 AM, Jakub Jelinek wrote: >>>>> On Mon, Jul 02, 2018 at 09:44:04AM +0200, Richard Biener wrote: >>>>>> Given the array has size i + 1 it's upper bound should be 'i' and 'i' >>>>>> should be available via DW_OP_[GNU_]entry_value. >>>>>> >>>>>> I see it is >>>>>> >>>>>> <175> DW_AT_upper_bound : 10 byte block: 75 1 8 20 24 8 20 26 31 >>>>>> 1c (DW_OP_breg5 (rdi): 1; DW_OP_const1u: 32; DW_OP_shl; >>>>>> DW_OP_const1u: 32; DW_OP_shra; DW_OP_lit1; DW_OP_minus) >>>>>> >>>>>> and %rdi is 1. Not sure why gdb fails to print it's length. Yes, the >>>>>> storage itself doesn't have a location but the >>>>>> type specifies the size. >>>>>> >>>>>> (gdb) ptype a >>>>>> type = char [variable length] >>>>>> (gdb) p sizeof(a) >>>>>> $3 = 0 >>>>>> >>>>>> this looks like a gdb bug to me? >>>>>> >>>> >>>> With gdb patch: >>>> ... >>>> diff --git a/gdb/findvar.c b/gdb/findvar.c >>>> index 8ad5e25cb2..ebaff923a1 100644 >>>> --- a/gdb/findvar.c >>>> +++ b/gdb/findvar.c >>>> @@ -789,6 +789,8 @@ default_read_var_value >>>> break; >>>> >>>> case LOC_OPTIMIZED_OUT: >>>> + if (is_dynamic_type (type)) >>>> + type = resolve_dynamic_type (type, NULL, >>>> + /* Unused address. */ 0); >>>> return allocate_optimized_out_value (type); >>>> >>>> default: >>>> ... >>>> >>>> I get: >>>> ... >>>> $ ./gdb -batch -ex "b f1" -ex "r" -ex "p sizeof (a)" vla-1.exe >>>> Breakpoint 1 at 0x4004a8: file vla-1.c, line 17. >>>> >>>> Breakpoint 1, f1 (i=i@entry=5) at vla-1.c:17 >>>> 17 return a[0]; >>>> $1 = 6 >>>> ... >>>> >>> >>> Well, for -O1 and -O2. >>> >>> For O3, I get instead: >>> ... >>> $ ./gdb vla-1.exe -q -batch -ex "b f1" -ex "run" -ex "p sizeof (a)" >>> Breakpoint 1 at 0x4004b0: f1. (2 locations) >>> >>> Breakpoint 1, f1 (i=5) at vla-1.c:17 >>> 17 return a[0]; >>> $1 = 0 >>> ... >>> >> >> Hi, >> >> When compiling guality/vla-1.c with -O3 -g, vla 'a[i + 1]' in f1 is optimized >> away, but f1 still contains a debug expression describing the upper bound of >> the >> vla (D.1914): >> ... >> __attribute__((noinline)) >> f1 (intD.6 iD.1900) >> { >> <bb 2> >> saved_stack.1_2 = __builtin_stack_save (); >> # DEBUG BEGIN_STMT >> # DEBUG D#3 => i_1(D) + 1 >> # DEBUG D#2 => (long intD.8) D#3 >> # DEBUG D#1 => D#2 + -1 >> # DEBUG D.1914 => (sizetype) D#1 >> ... >> >> Then f1 is cloned to a version f1.constprop with no parameters, eliminating >> parameter i, and 'DEBUG D#3 => i_1(D) + 1' turns into 'D#3 => NULL'. >> Consequently, 'print sizeof (a)' yields '0' in gdb. > > So does gdb correctly recognize there isn't any size available or do we > somehow > generate invalid debug info, not recognizing that D#3 => NULL means > "optimized out" and thus all dependent expressions are "optimized out" as > well? > > That is, shouldn't gdb do > > (gdb) print sizeof (a) > <optimized out> > > ?
The type for the vla gcc is emitting is an DW_TAG_array_type with DW_TAG_subrange_type without DW_AT_upper_bound or DW_AT_count, which makes the upper bound value 'unknown'. So I'd say the debug info is valid. Using this gdb patch: ... diff --git a/gdb/eval.c b/gdb/eval.c index 9db6e7c69d..ea6f782c5b 100644 --- a/gdb/eval.c +++ b/gdb/eval.c @@ -3145,6 +3145,8 @@ evaluate_subexp_for_sizeof (...) { val = evaluate_subexp (NULL_TYPE, exp, pos, EVAL_NORMAL); type = value_type (val); + if (TYPE_LENGTH (type) == 0) + return allocate_optimized_out_value (size_type); } else (*pos) += 4; ... I get: ... $ ./gdb vla-1.exe -batch -ex "b f1" -ex run -ex "p sizeof (a)" Breakpoint 1 at 0x4004b0: f1. (2 locations) Breakpoint 1, f1 (i=5) at vla-1.c:17 17 return a[0]; $1 = <optimized out> ... Thanks, - Tom