Hi Harald and Jerry,
thanks for taking the time to read my false assumptions ;-)
The assumption that v1%n(n:m, m:n) => v2%n(m:n, n:m) is valid in a pointer
remapping is wrong. (F2018 ยง10.2.2.3 paragraph 9). The rhs is neither simply
contiguous nor of rank one and therefore rejected. I spent some
Hi Andre,
Am 06.03.25 um 09:15 schrieb Andre Vehreschild:
Hi Harald,
I try to explain why I think my patch although solving the issue for this case,
does not do so in every case:
My patch lets dependency analysis figure that the two objects can not have any
dependencies on each other or memory
Hi Harald,
I try to explain why I think my patch although solving the issue for this case,
does not do so in every case:
My patch lets dependency analysis figure that the two objects can not have any
dependencies on each other or memory they are pointing to when the types are
different. Lets assu
Hi Andre,
Jerry already OK'ed your patch, but:
Am 05.03.25 um 15:34 schrieb Andre Vehreschild:
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
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 =>
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
