This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [testsuite/guality, committed] Prevent optimization of local in vla-1.c


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
...

So I'd say it's a gdb bug indeed.

Thanks,
- Tom

>> Btw, the location expression looks odd, if I deciper it correctly
>> we end up with ((%rdi << 32) >> 32) - 1 which computes to 4
>> but the upper bound should be 5.  The GIMPLE debug stmts compute
>> the upper bound as (sizetype)((long)(i_1(D) + 1) - 1)
> 
> The << 32 >> 32 is sign extension.  And yes, for f1 I don't see why
> DW_OP_GNU_entry_value shouldn't work, i in main is needed for the call to
> f2, so needs to live in some register or memory in that function until the
> second call.  For f2 i is needed after the bar call for the a[i + 4] read,
> worst case in form of precomputed i + 4, but that is reversible op.
> 
> 	Jakub
> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]