> 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;
> 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
