Hi Andre,
Thanks for all these comments, aka early review:
>
> + if (formal->sym->attr.allocatable || formal->sym->attr.allocatable
> + || formal->sym->attr.pointer || formal->sym->attr.pointer
> + || formal->sym->attr.optional || formal->sym->attr.optional
> + || formal->sym->ts
Hi Harald,
thanks for the review. Committed as gcc-15-7826-g705ae582d51.
The fix for pr107143 may be something similar. I am having a harder time getting
a testcase correct, then fixing the gimplification fault (that's fixed, but the
test is fouling me).
Thanks again,
Andre
On Tue, 4 Ma
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
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
