Thanks.
I just filed a PR https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111030 to record
this issue and added you to the CC list.
Qing
> On Aug 15, 2023, at 6:57 AM, Siddhesh Poyarekar <siddh...@gotplt.org> wrote:
>
> On 2023-08-14 19:12, Qing Zhao wrote:
>> Hi, Sid,
>> For the following testing case:
>> #include <stdio.h>
>> #define noinline __attribute__((__noinline__))
>> static void noinline alloc_buf_more (int index)
>> {
>> struct annotated {
>> long foo;
>> char b;
>> char array[index];
>> long c;
>> } q, *p;
>> p = &q;
>> printf("the__bdos of p->array whole max is %d \n",
>> __builtin_dynamic_object_size(p->array, 0));
>> printf("the__bdos of p->array sub max is %d \n",
>> __builtin_dynamic_object_size(p->array, 1));
>> printf("the__bdos of p->array whole min is %d \n",
>> __builtin_dynamic_object_size(p->array, 2));
>> printf("the__bdos of p->array sub min is %d \n",
>> __builtin_dynamic_object_size(p->array, 3));
>> return;
>> }
>> int main ()
>> {
>> alloc_buf_more (10);
>> return 0;
>> }
>> If I compile it with the latest upstream gcc and run it:
>> /home/opc/Install/latest-d/bin/gcc -O t.c
>> the__bdos of p->array whole max is 23
>> the__bdos of p->array sub max is 23
>> the__bdos of p->array whole min is 23
>> the__bdos of p->array sub min is 23
>> In which__builtin_dynamic_object_size(p->array, 0) and
>> __builtin_dynamic_object_size(p->array, 1) return the same size, this seems
>> wrong to me.
>> There is one line in tree-object-size.cc might relate to this bug: (in the
>> routine “addr_object_size”)
>> 603 if (! TYPE_SIZE_UNIT (TREE_TYPE (var))
>> 604 || ! tree_fits_uhwi_p (TYPE_SIZE_UNIT (TREE_TYPE (var)))
>> 605 || (pt_var_size && TREE_CODE (pt_var_size) == INTEGER_CST
>> 606 && tree_int_cst_lt (pt_var_size,
>> 607 TYPE_SIZE_UNIT (TREE_TYPE
>> (var)))))
>> 608 var = pt_var;
>> I suspect that the above line 604 “ ! tree_fits_uhwi_p (TYPE_SIZE_UNIT
>> (TREE_TYPE (var)))” relates to this bug, since the TYPESIZE of the VLA
>> “array” is not a unsigned HOST_WIDE_INT, but we still can use its TYPESIZE
>> for dynamic_object_size?
>> What do you think?
>
> Thanks, yes that doesn't work. I'm trying to revive the patch I had
> submitted earlier[1] in the year and fix this issue too in that process. In
> general the subobject size computation doesn't handle variable sizes at all;
> it depends on whole object+offset to get size information, which ends up
> working only for flex arrays at the end of objects.
>
> Sid
>
> [1] https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608914.html
