Hi Tobias, On Fri, Sep 12, 2025 at 9:08 PM Tobias Burnus <[email protected]> wrote: > I am unsure if this is the most appropriate place to simplify. > > I am very much in favor of deferring it. Plus: I am wondering > whether it is generally okay to just simplify it here – or whether > it has to be delayed to a later resolving stage. For constants, when > used in the executable part, it is probably okay – but in the > specification part, it likely breaks. > > If we need to defer it, then the check would be later in > resolve_omp_clauses, but we then have to save the expression > (gfc_expr*) instead of a flag ('bool', 'int …:1'). > > In any case, that's something unrelated to the patch itself. >
I've got a quick question about the collapse clause in OpenMP. I've been looking at the standard, specifically section 6.4.5, and it says that the value of 'n' can't be greater than the loop nest depth. But it doesn't seem to specify what kind of expression you can use for 'n' in C++ or Fortran. >From a compiler writer's perspective, how should we handle this? Maybe use any valid integer expression that resolves correctly? Or are there other rules I might've missed? > * * * > > Subject: [PATCH] fortran: implement conditional expression for fortran 2023 > > This patch adds support for conditional expressions in Fortran 2023 for a > limited set of types (logical, numerical), and also includes limited support > for conditional arguments without `.nil.` support. > > LGTM. Thanks! > Thank you for the thorough review! I think the patch is okay for trunk now(Bootstrapped and regression tested on an x86_64 Linux)? I will wait a day or so for any additional comments before committing it. In the meantime, I will start working on the nil part. Cheers, Yuao
