[Bug tree-optimization/111040] New: __builtin_object_size: inconsistent result for subobject with member arrays.

[Bug tree-optimization/111040] New: __builtin_object_size: inconsistent result for subobject with member arrays.

[qinzhao at gcc dot gnu.org]

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

            Bug ID: 111040
           Summary: __builtin_object_size: inconsistent result for
                    subobject with member arrays.
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: qinzhao at gcc dot gnu.org
  Target Milestone: ---

__bos produces different results for subobject with different optimizations:

#include <stddef.h>
#include <stdio.h>

#define noinline __attribute__((__noinline__))

struct fixed {
  size_t foo;
  char b;
  char array[10]; 
} q = {};

static void noinline bar ()
{
  struct fixed *p = &q;

  printf("the__bdos of max p->array sub is %d \n",
__builtin_dynamic_object_size(p->array, 1)); 

  return;
}

int main ()
{
  bar ();
  return 0;
}

when compiled with 
/home/opc/Install/latest-d/bin/gcc -O -fstrict-flex-arrays=3 t.c
./a.out
the__bdos of max p->array sub is 10 

when compiled with (disable the early object size pass):
/home/opc/Install/latest-d/bin/gcc -O -fstrict-flex-arrays=3
-fdisable-tree-early_objsz t.c
./a.out
the__bdos of max p->array sub is 15 

I assume that the correct result for __builtin_dynamic_object_size(p->array, 1)
should be 10.

[Bug tree-optimization/111040] __builtin_object_size: inconsistent result for subobject with member arrays.

[qinzhao at gcc dot gnu.org]

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

--- Comment #1 from qinzhao at gcc dot gnu.org ---
an initial study inside gdb shows the following:

1. the guilty pass is "ccp1", when folding the call to
__builtin_dynamic_object_size(p->array, 1)
2. In this pass, the IR for p->array is represented as: (stop at routine
"addr_object_size") 
(gdb) call debug_generic_expr(ptr)
&MEM <char[10]> [(void *)&q + 9B]

(gdb) call debug_generic_expr(pt_var)
MEM <char[10]> [(void *)&q + 9B]

therefore the following condition at line 585:
 585   if (pt_var != TREE_OPERAND (ptr, 0))
 586     {
 587       tree var;

was not satisfied, the computation for size of the sub-object is not invoked at
all. as a result, the size for the whole object is used instead. therefore the
wrong result.

I suspect that this is a bug in tree-object-size.cc that cannot handle the IR
&MEM <char[10]> [(void *)&q + 9B] correctly. Current algorithm can only handle
the IR p->array correctly

[Bug tree-optimization/111040] __builtin_object_size: inconsistent result for subobject with member arrays.

[qinzhao at gcc dot gnu.org]

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

--- Comment #2 from qinzhao at gcc dot gnu.org ---
the discussion on this bug is at:
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627631.html

[Bug tree-optimization/111040] __builtin_object_size: inconsistent result for subobject with member arrays.

[qinzhao at gcc dot gnu.org]

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

--- Comment #3 from qinzhao at gcc dot gnu.org ---
a summary of the discussion:

We have two different sources to get the size information for subobjects:
   A. The TYPE information of the subobject in the IR;
   B. The initialization information propagated through data flow.

In the early pass, only A is available.
B might be available in the second pass.

If both A and B are available, we should choose the minimum one between
these two for both OST_MINIMUM and OST_MAXIMUM.

However, in the current early object size phase, we have the following:

enum tree_code code = object_size_type & OST_MINIMUM ? MAX_EXPR : MIN_EXPR;

I.e, we chose the MAX one between A and B for OST_MIN.