On Tue, Apr 22, 2025 at 5:22 PM Qing Zhao <[email protected]> wrote:
>
> Hi,
>
> I have met the following issue when I tried to implement the following into
> tree-object-size.cc:
> (And this took me quite some time, still don’t know what’s the best solution)
>
> > On Apr 16, 2025, at 10:46, Qing Zhao <[email protected]> wrote:
> >
> > 3. When generating the reference to the field member in tree-object-size,
> > we should guard this reference with a checking
> > on the pointer to the structure is valid. i.e:
> >
> > struct annotated {
> > size_t count;
> > char array[] __attribute__((counted_by (count)));
> > };
> >
> > static size_t __attribute__((__noinline__)) size_of (struct annotated * obj)
> > {
> > return __builtin_dynamic_object_size (obj, 1);
> > }
> >
> > When we try to generate the reference to obj->count when evaluating
> > __builtin_dynamic_object_size (obj, 1),
> > We should generate the following:
> >
> > If (obj != NULL)
> > * (&obj->count)
> >
> > To make sure that the pointer to the structure object is valid first.
> >
>
> Then as I generate the following size_expr in tree-object-size.cc:
>
> Breakpoint 1, gimplify_size_expressions (osi=0xffffffffdf30)
> at ../../latest-gcc-write/gcc/tree-object-size.cc:1178
> 1178 force_gimple_operand (size_expr, &seq, true, NULL);
> (gdb) call debug_generic_expr(size_expr)
> _4 = obj_2(D) != 0B ? (sizetype) (int) MAX_EXPR <(sizetype) MAX_EXPR <MEM
> <int> [(void *)&*obj_2(D)], 0> + 4, 4> : 18446744073709551615
>
> When calling “force_gimple_operand” for the above size_expr, I got the
> following ICE in gimplify_modify_expr, at gimplify.cc:7505:
You shouldn't really force_gimple_operand to a MODIFY_EXPR but instead
only to its RHS.
> (gdb) c
> Continuing.
> during GIMPLE pass: objsz
> dump file: a-t.c.110t.objsz1
> In function ‘size_of’:
> cc1: internal compiler error: in gimplify_modify_expr, at gimplify.cc:7505
> 0x36feb67 internal_error(char const*, ...)
> ../../latest-gcc-write/gcc/diagnostic-global-context.cc:517
> 0x36ccd67 fancy_abort(char const*, int, char const*)
> ../../latest-gcc-write/gcc/diagnostic.cc:1749
> 0x14fa8ab gimplify_modify_expr
> ../../latest-gcc-write/gcc/gimplify.cc:7505
> 0x15354c3 gimplify_expr(tree_node**, gimple**, gimple**, bool
> (*)(tree_node*), int)
> ../../latest-gcc-write/gcc/gimplify.cc:19530
> 0x14fe1b3 gimplify_stmt(tree_node**, gimple**)
> ../../latest-gcc-write/gcc/gimplify.cc:8458
> ….
> 0x1b07757 gimplify_size_expressions
> ../../latest-gcc-write/gcc/tree-object-size.cc:1178
>
> I debugged into this a little bit, and found that the following are the
> reason for the assertion failure in the routine “gimplify_modify_expr” of
> gimplify.cc:
>
> 1. The assertion failure is:
>
> 7502 if (gimplify_ctxp->into_ssa && is_gimple_reg (*to_p))
> 7503 {
> 7504 /* We should have got an SSA name from the start. */
> 7505 gcc_assert (TREE_CODE (*to_p) == SSA_NAME
> 7506 || ! gimple_in_ssa_p (cfun));
> 7507 }
>
> 2. The above assertion failure is issued for the following temporary tree:
>
> (gdb) call debug_generic_expr(*to_p)
> iftmp.2
> (gdb) call debug_generic_expr(*expr_p)
> iftmp.2 = (sizetype) _10
>
> In the above, the temporary variable “iftmp.2” triggered the assertion since
> it’s NOT a SSA_NAME but the gimple_in_ssa_p (cfun) is TRUE.
>
> 3. As I checked, this temporary variable “iftmp.2” was generated at line 5498
> in the routine “gimplify_cond_expr” of gimplify.cc:
>
> 5477 /* If this COND_EXPR has a value, copy the values into a temporary
> within
> 5478 the arms. */
> 5479 if (!VOID_TYPE_P (type))
> 5480 {
> …..
> 5498 tmp = create_tmp_var (type, "iftmp”);
> ...
> 5537 }
>
> 4. And then later, this temporary created here “iftmp.2” triggered the
> assertion failure.
>
> Right now, I have the following questions:
>
> 1. Can I generate a size_expr as complicate as the following in
> tree-object-size.cc:
>
> _4 = obj_2(D) != 0B ? (sizetype) (int) MAX_EXPR <(sizetype) MAX_EXPR <MEM
> <int> [(void *)&*obj_2(D)], 0> + 4, 4> : 18446744073709551615
>
> 2. If Yes to 1, is this a bug in “gimplify_cond_expr”? Shall we call
> “make_ssa_name” after the call to “create_tmp_var” if “gimple_in_ssa_p(cfun)”
> is TRUE?
>
> 3. If No to 1, how can we check whether the pointer is zero before
> dereference from it to access its field?
>
> Thanks a lot for any hints.
>
> Qing
