Re: [PATCH v4 6/7] OpenMP: Fortran front-end support for dispatch + adjust_args

2024-12-16 Thread Tobias Burnus
Hi PA, Paul-Antoine Arras wrote: See the revised patch attached and my comments below. First, for Fortran patches, please also CC fortran@ besides gcc-patches@. The original patch email can be found at: https://gcc.gnu.org/pipermail/gcc-patches/2024-December/671763.html I have not looked in

Re: [Fortran, Patch, PR117347, v2] Fix array constructor not resolved in associate

2024-12-16 Thread Harald Anlauf
Hi Andre, Am 16.12.24 um 15:26 schrieb Andre Vehreschild: Hi Harald, thanks for finding the bug so quickly. I took another look and came up with the attached trivially looking patch, which replaces the old version 1 entirely. The new v2 version of the patch just makes use of existing code gues

Re: [Fortran, Patch, PR117347, v2] Fix array constructor not resolved in associate

2024-12-16 Thread Andre Vehreschild
Hi Harald, thanks for finding the bug so quickly. I took another look and came up with the attached trivially looking patch, which replaces the old version 1 entirely. The new v2 version of the patch just makes use of existing code guessing the type of the associate variable, which once I found i

Re: [Fortran, Patch, PR107635, Part 1] Rework handling of allocatable components in derived type coarrays.

2024-12-16 Thread Damian Rouson
This is a big deal, Andre! Thanks for working on this patch. I have some test code that I can dig up if that’s helpful. Have you tested with nested derived type components, i.e., allocatable components that are themselves derived types that have allocatable components? The need for this featur

Re: [PING!, Fortran, Patch, PR107635, Part 1] Rework handling of allocatable components in derived type coarrays.

2024-12-16 Thread Andre Vehreschild
PING! On Fri, 6 Dec 2024 19:10:08 +0100 Andre Vehreschild wrote: > Hi all, > > I had to dive deeply into the issue with handling allocatable components in > derived types and to find a future proof solution. I hope do have found a > universal and flexible one now: > > For each allocatable (or po