Hi all,
(mostly my fault that the original email didn't went to the mailing lists.)
Yuao Ma wrote:
On Thu, Oct 16, 2025 at 5:47 PM Tobias Burnus <[email protected]> wrote:
+ /* TODO: support array for conditional expressions */
Shouldn't this be, e.g.,
- TODO: support arrays in conditional expressions
- TODO: conditional expressions with arrays
- TODO: array support for/in conditional expressions
Thus, I think this tiny change and the gfc_is_proc_ptr_comp is all
what's required for this patch, i.e. it should be quick.
Done.
* * *
* * *
Otherwise, LGTM.
Thanks for the patch!
* * *
PS: I was a bit unsure whether the string-length evaluation
properly handles se.pre/se.post, but it does:
i.e. no action required – unless you want to add a testcase for it.
I checked this program locally today. The original tree dump behaves
as expected. The key seems to be that the pre/post block is properly
handled in the cond-expr condgen part; we just need to propagate the
string_length attribute. It looks like it works as expected.
As a side question, is ALLOCATE unnecessary in Fortran for this
particular program?
I assume that relates to:
integer, allocatable :: f
f = x
If so: Fortran (re)allocates the left-hand as needed,
i.e. if 'f' is unallocated (which it is by construction)
it will be allocated - to the same array shape and
character length as the RHS. As in:
f = "hello world"
If it is already allocated - suitable for the RHS, the
allocation remains as it was.
In this case, 'x' is unallocated – but it is also not
called.
(That relates to:)
implicit none (type, external)
integer, allocatable :: x
print *, (allocated (x) ? "abcded"(1:f()) : "bar")
contains
function f()
integer, allocatable :: f
f = x
end
end
* * *
The updated character patch is attached. I'll commit this over the
weekend if there are no objections.
Sorry for the delay. Yes, LGTM.
Thanks,
Tobias
