When expansion was disabled, e.g. in GNATprove mode or when switch
-gnatc was used, analysis of the iterated_component_association's
expression was crashing when the expression included a function call.
The problem was that a copy of the expression was created with empty
parent. Then an access-before-elaboration call marker was inserted as
an action associated with this empty parent, which cannot work.
When expansion is enabled, e.g. when compiling the code as usual, then
analysis of the iterated_component_association's expression only happens
after expansion, where the parent link was set. (The decision whether to
analyze the expression's copy and not wait until it is fully expanded it
explained in a comment in Resolve_Aggr_Expr.)
Tested on x86_64-pc-linux-gnu, committed on trunk
gcc/ada/
* sem_aggr.adb (Resolve_Iterated_Component_Association):
Expression's copy and now has the same parent as the original
expression.
(Resolve_Array_Aggregate): Add ??? comment about a still
existing minor issue that led to discovery of the above crash.diff --git a/gcc/ada/sem_aggr.adb b/gcc/ada/sem_aggr.adb
--- a/gcc/ada/sem_aggr.adb
+++ b/gcc/ada/sem_aggr.adb
@@ -1662,6 +1662,7 @@ package body Sem_Aggr is
-- as a loop with a new index variable.
Expr := New_Copy_Tree (Expression (N));
+ Set_Parent (Expr, N);
Dummy := Resolve_Aggr_Expr (Expr, False);
-- An iterated_component_association may appear in a nested
@@ -2057,8 +2058,13 @@ package body Sem_Aggr is
return Failure;
end if;
+ -- ??? Checks for dynamically tagged expressions below will
+ -- be only applied to iterated_component_association after
+ -- expansion; in particular, errors might not be reported when
+ -- -gnatc switch is used.
+
elsif Nkind (Assoc) = N_Iterated_Component_Association then
- null; -- handled above, in a loop context.
+ null; -- handled above, in a loop context
elsif not Resolve_Aggr_Expr
(Expression (Assoc), Single_Elmt => Single_Choice)
