On Mon, Sep 15, 2025 at 1:44 PM Eric Botcazou <[email protected]> wrote:
>
> > Ah, I wasn't aware of that. This makes TREE_THIS_NOTRAP possibly not
> > usable for tree_could_trap_p :/ One could read the docs so that it means
> > when you have a read with TREE_THIS_NOTRAP then you can't infer
> > from that that writing to it is OK though. Rather than meaning that a write
> > with TREE_THIS_NOTRAP meaning that write could still trap when the store is
> > to readonly memory?
>
> My understanding is that this means that you may set both flags on a given
> dereference, that's what we do in the Ada front-end:
>
> /* Some objects (such as parameters passed by reference, globals of
> variable size, and renamed objects) actually represent the address
> of the object. In that case, we must do the dereference. Likewise,
> deal with parameters to foreign convention subprograms. */
> if (DECL_P (gnu_result)
> && (DECL_BY_REF_P (gnu_result)
> || (TREE_CODE (gnu_result) == PARM_DECL
> && DECL_BY_COMPONENT_PTR_P (gnu_result))))
> [...]
> /* Do the final dereference. */
> gnu_result = build_unary_op (INDIRECT_REF, NULL_TREE, gnu_result);
>
> if ((INDIRECT_REF_P (gnu_result)
> || TREE_CODE (gnu_result) == UNCONSTRAINED_ARRAY_REF)
> && No (Address_Clause (gnat_entity)))
> TREE_THIS_NOTRAP (gnu_result) = 1;
>
> if (read_only)
> TREE_READONLY (gnu_result) = 1;
Yes. So I read the comment in a way to say that TREE_THIS_NOTRAP does not
mean the reference is writable. In some context we check
|| tree_could_trap_p (lhs)
/* tree_could_trap_p is a predicate for rvalues, so check
for readonly memory explicitly. */
|| ((base = get_base_address (lhs))
&& ((DECL_P (base)
&& TREE_READONLY (base))
|| TREE_CODE (base) == STRING_CST)))
return false;
but I guess even for !DECL_P base but tcc_reference base TREE_READONLY
could be set? I've never seen that though. Not having TREE_READONLY set
on some handled-component doesn't mean a ref is writable, right? So it's kind
of a useless flag when put on reference trees?
Richard.
> > Understood. Note I'm completely unsure as to what extent we see
> > TREE_THIS_NOTRAP being used (from frontends). I know OpenMP lowering
> > uses it quite extensively, IIRC also nested function lowering. Grepping
> > finds a single use outside of Ada, in go-gcc.cc
>
> Yes, Go also enables -fnon-call-exceptions and you need TREE_THIS_NOTRAP to
> avoid creating annoying edges in the CFG in this context; at least adding an
> additional test on type_contains_placeholder_p in the change to the inliner
> will rule it out since it does not use PLACEHOLDER_EXPRs.
>
> --
> Eric Botcazou
>
>
