Hi! Christopher et al., first: Thanks for your work on this (see below) and other bug fixes!
On 2026-04-13T12:38:51-0700, Jerry D <[email protected]> wrote: > On 4/13/26 12:20 PM, Harald Anlauf wrote: >> Am 11.04.26 um 6:54 PM schrieb Jerry D: >>> The attached patch look fairly simple. >>> >>> Regression tested on x86_64. >>> >>> I plan to commit this one in a little while. >> >> Does this need RM approval? It's a change below gcc/ . > > We were given a week at the start of last week. Not sure what that last comment actually relates to, but: this patch doesn't change GCC/Fortran code, but generic GCC middle end infrastructure, 'gcc/omp-expand.cc:expand_oacc_for' (OpenACC 'loop' construct handling). I note that this commit also resolves the ICEs reported in <https://gcc.gnu.org/PR95550> "[OpenACC] ICE in expand_oacc_for, at omp-expand.c:6075", and <https://gcc.gnu.org/PR107227> "Compiler bug in private allocatable array in OpenACC compute statement", so these PRs need to be verified if they're indeed completely resolved now (duplicates), or if other work remains, and/or whether their test cases should also be installed. > This one is pushed already as of April 11, 2026 <https://gcc.gnu.org/g:010618b8dcb73220790f8f82cf76e8a2aacc2122> "fortran: Fix ICE in expand_oacc_for with private derived type [PR93554]". > No worries here. It's easy to make assertion failures go away by just defusing the 'assert's. ;-) (And also: removing 'assert's won't make any conforming code misbehave, so this commit doesn't introduce any regressions for conforming code.) However, are we really convinced that any follow-on middle end, back end compiler handling is correct for the "more loose" basic block layout that we now accept? From the discussion in the PR initially by Tobias (CC added), and later Christopher, I can see that some thought has been spent on this, but the test case that we currently have (per the commit) certainly isn't able to verify this: in other words, this isn't sufficient, and we need a thorough review of the code (changes) and their effect on later compiler passes, and proper execution test case(s) added, exercising this now-enabled functionality in context of OpenACC's (different levels of) parallelism, relevant different data types (see the other PRs I've mentioned, for example), etc. I shall try to help with review of the OpenACC side of things, but I'll appreciate help with the Fortran side of things (as producer of this previously-rejected code). Christopher, can you please elaborate to which extent you've verified (by inspection and/or testing) the code changes? Grüße Thomas
