https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117018
--- Comment #2 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Marc Poulhi?s <d...@gcc.gnu.org>: https://gcc.gnu.org/g:23273ed381608382dd4cbc2a28f1ec7342eee149 commit r15-5134-g23273ed381608382dd4cbc2a28f1ec7342eee149 Author: Eric Botcazou <ebotca...@adacore.com> Date: Wed Oct 23 09:42:25 2024 +0200 ada: Fix internal error on nested iterated component associations The problem is that Insert_Actions gets confused as to where it should insert actions coming from within an N_Iterated_Component_Association, because some actions may be generated during semantic analysis and some others during expansion. Instead of another ad-hoc fix, this change extends the processing done for N_Component_Association, that is to say waiting for the Loop_Actions field to be set during expansion before inserting actions in there. This in turn requires semantic analysis to stop generating actions for N_Iterated_Component_Association nodes. The current processing is a little unstable: - for container aggregates, Resolve_Iterated_Association preanalyzes a copy of the expression, - for delta aggregates, Resolve_Delta_Array_Aggregate fully analyzes a copy of the expression, - for array aggregate, Resolve_Aggr_Expr entirely skips the analysis. The change implements a preanalysis of a copy of the expression using Copy_Separate_Tree, which should be sufficient since the expression is supposed to be unanalyzed at this point, recursively in the context of N_Iterated_Component_Association nodes. gcc/ada/ChangeLog: PR ada/117018 * exp_aggr.adb (Build_Array_Aggr_Code): Do not expect the Loop_Actions field to be already present on association nodes. * exp_util.adb (Insert_Actions): For association nodes, insert into the Loop_Actions field only if it is already present. * sem_aggr.adb (Resolve_Array_Aggregate): Add Iterated parameter. (Resolve_Aggregate): Adjust calls to Resolve_Array_Aggregate. (Resolve_Aggr_Expr): Add Iterated_Elmt defaulted parameter and a default for Single_Elmt. Adjust call to Resolve_Array_Aggregate. Preanalyze a copy of the expression in an iteration context. (Resolve_Iterated_Component_Association): Pass Iterated_Elmt as True to Resolve_Aggr_Expr and remove processing of Loop_Actions. Do not check incorrect use of dynamically tagged expression in an iteration context. (Resolve_Iterated_Association): Use Copy_Separate_Tree instead of New_Copy_Tree and set the Parent field of the result. (Resolve_Delta_Array_Aggregate): Likewise. Only preanalyze the copy instead of analyzing it.
