> I think we really need Eric (as one who e.g. introduced the
> DECL_INVARIANT_P apparently for this kind of stuff) to have a look at that
> on the Ada side.

I have been investigating this for a few days and it's no small change for Ada 
and probably for other languages with dynamic types.  SAVE_EXPRs are delicate 
to handle because 1) they are TREE_SIDE_EFFECTS (it's explained in save_expr) 
so out of TREE_READONLY && !TREE_SIDE_EFFECTS trees, you now get side effects 
which then propagate to all parent nodes 2) their placement is problematic in 
conditional expressions, for example if you replace

  cond > 0 ? A : A + 1

with

  cond > 0 ? SAVE_EXPR (A) : SAVE_EXPR (A) + 1

then gimplification will, say, create the temporary and initialize it in the 
first arm so, if at runtime you take the second arm, you'll read the temporary 
uninitialized.  That's caught for scalar values by the SSA form (if your patch 
is applied to a GCC 12 tree, you'll get ICEs in the ACATS testsuite because of 
this through finalize_type_size -> variable_size -> save_expr, it is probably 
mitigated/addressed in GCC 14 by 68e0063397ba820e71adc220b2da0581dce29ffa).
That's also why making gnat_invariant_expr return (some of) them does not look 
really safe.

In addition to this, in Ada we have bounds of unconstrained arrays which are 
both read-only and stored indirectly, i.e. you have an INDIRECT_REF in the 
tree (it is marked TREE_THIS_NOTRAP because the bounds are always present), 
and which obviously play a crucial role in loops running over the arrays.
This issue is responsible for the regressions in the gnat.dg testsuite.

I think that we can reasonably deal with the second issue in the Ada front-end 
because we know the semantics of the bounds of unconstrained arrays, and I'm 
testing a patch to that effect, but the first issue might be annoying too.

-- 
Eric Botcazou


Reply via email to