On Mon, Sep 15, 2025 at 11:23 AM Eric Botcazou <[email protected]> wrote:
>
> > Do we need to ensure that, for the MEM_REF case at least, the DECL is of
> > appropriate size with respect to the TREE_TYPE of the MEM_REF and
> > the offset (TREE_OPERAND (*tp, 1))?  That is, consider
> >
> >  ptr = &too_small_object;
> >  if (object-of-OK-size)
> >    foo (*(larget-type *)ptr);
> >
> > if we set TREE_THIS_NOTRAP that makes an inlined access OK to be hoisted
> > above the object-of-OK-size check.
>
> The thing is, if we could do that easily, we could do it in tree_could_trap_p
> directly (that's the first thing I tried).  But, in the cases at stake, the
> type of the parameter is self-referential, meaning that its TREE_SIZE contains
> a PLACEHOLDER_EXPR, possibly nested in a CALL_EXPR, so no simple offset/size
> calculation as implemented by ref_outside_object_p can be sufficient.
>
> In these cases, there is no need for an object-of-OK-size check in the caller
> since the callee can handle "all" the possible sizes.  That's admittedly tied
> to the Ada semantics, so I can add a test on type_contains_placeholder_p here.

Yes please.  Can we assert the MEM_REF offset is zero and the MEM_REF
isn't type-punning, aka TREE_TYPE of the MEM_REF is compatible with
the decls type, or is this not easily possible (again because of the
placeholders)?

> > It might also be a if (object-writable) check and an inlined store, where
> > we'd have to consider a readonly decl?
>
> I think there is no possible such check in Ada and that you cannot invoke a
> subprogram that contains a store on a readonly object without invoking a
> (bounded) erroneous execution in the program.

But the subprogram invocation would be guarded with a check for writability.

The issue is that TREE_THIS_NOTRAP is "global" and not flow-sensitive.

Richard.

> --
> Eric Botcazou
>
>

Reply via email to