On 3/5/25 6:34 AM, Andre Vehreschild wrote:
Hi all,attached patch fixes a gimplification error when a pointer remapping on derived type's components with deferred arrays is made. The issue boiled down to the dependency analysis being to loose. It saw a dependency as soon as both sides of the => had a derived type, independent of the actual derived types used. The patch therefore extends the dependency analysis to compare also the derived types (symbols). This fixes the PR, but not really the problem, because when say a obj(i)%arr(2:5) => obj(i)%arr(1:4) is done we run into the same issue. I don't have a solution for that error. It might be needed to prevent generating the parm.NN variable for the lhs, because that is mostly useless there. (Or I don't understand (yet) how to use it). Regstests ok on x86_64-pc-linux-gnu / F41. Ok for mainline or other suggestions? Regards, Andre -- Andre Vehreschild * Email: vehre ad gmx dot de
This looks simple enough. OK. One minor nit in git log "Enhance dependency checking for data pointers to check for same derived type and not only for a type being a derived type. This prevent generation of a descriptor for a function call, that is unsuitable in forall's pointer assignment." s/prevent/prevents/ -- Jerry
