`move_alloc()` for the function result

Hello,

Is it legal to pass the result variable of a function (which returns an allocatable variable) and use move_alloc() to move the function result to another allocatable variable ? Something like…

program main
  implicit none
  integer, allocatable :: a(:)

  call move_alloc(make_array(), a)

contains

  function make_array() result(res)
    integer, allocatable :: res(:)
    allocate(res(3))
    res = [1, 2, 3]
  end function

end program

Is it also legal to move an allocatable component of a non-allocatable function result to another allocatable variable via move_alloc()…?

If they are legal, is it OK to assume that only one allocation occurs in the move_alloc() statement (for the moved variable)?

(By the way, AI automatically tries to modify my title by capitalizing move to Move… XD)

In yout code, make_array() is an expression, which is not compatible with intent(inout)… And, from the point of view of an expression, the allocatable attribute is already lost.

Yes, that is exactly what I first thought (so I had never tried it with compilers before), but today I happened to ask the first paragraph in my post to both Gemini and ChatGPT (for curiosity). Then, both of them replied very confidently that “they are legal” and provided a sample code shown above. So, I just wanted to hear other people’s opinions. (FYI, I have just tried both gfortran and flang, and they just rejected the code.)

The reply of Gemini is here. The confusion of AI may come from the scarcity of literature (particularly related corner cases). Overall, I guess asking Fortran questions to AI might need more caution (than e.g. Python) if they are related to not so common usage…

(But otherwise, I really feel both the latest Gemini and ChatGPT are great, especially for literature summary (for Gemini) and math/physics discussions (ChatGPT). So the fields they are strong may vary…)

I tried this example with Claude 4.7 and got

● No, that’s not legal.

move_alloc(from, to) declares from as intent(inout) and requires it to be an allocatable variable. A function reference like
make_array() is an expression, not a variable — even though the function result happens to be declared allocatable internally, what’s
passed to the caller is a value, and you can’t pass an expression to an intent(inout) dummy.

The intended idiom here is just plain assignment, which since F2003 does automatic (re)allocation from an allocatable function result
with no copy needed in most implementations:

a = make_array()

It’s not just a Fortran thing. LLMs in general are trained to give you a result, no matter what —and if the result happens to be a gateway for further prompting, then their goal is achievced.

I have the tendency to ask for stuff in C-related terms, even if my actual intent is Fortran, and the results are not better —the one that stunned me the most was when ChatGPT’s output confidently included the int66_t type multiple times.

Another funny thing is that, when confronted about the falsehood of their claims, LLMs tend to hallucinate lengthy and confusing explanations.

My point is that LLMs are just assistants that can never be blindly trusted. YMMV.

Very interesting. I usually use LLMs for Python, and the results are very useful and time-saving for me (rather than digging various pages manually). But for rigorous purposes like checking syntax correctness (like above), it may be better not to trust it very much (unless we check the original literature shown by LLMs also).

For the above case of Claude, I wonder it may have already utilized RAG, so reflecting the output here on the Discourse (that was my previous experience with ChatGPT or something, which almost immediately reflected the discussions on this Dicourse site). So, I guess the output depends on the timing we ask.

For math/physics questions and discussions, on the other hand, I am very happy with its capability for step-by-step derivations etc, which are very helpful for learning new things (at least as a starter). Also, I have been using them extensively for literature search and survey, which I also feel very useful. On the other hand, for generating numerical codes or asking syntax correctness, I am still very cautious about them (so currently not using them for that purpose very much, unlike questions about various libraries in Python, installation or command usage, etc, etc).

EDIT: When I further provided the output of flang and gfortran (compilation error) to both Gemini(3.5-Flash) and ChatGPT(5.5), both of them started to agree that the code is illegal. Interestingly, ChatGPT started to use the Thinking mode after I gave the compiler output and gathered a lot more pages and references. I then asked the same question using “temporary chats” for both LLMs, and they now give the correct answer in any case… (irrespective of Instant or Thinking mode). I will next try asking this kind of questions in the Thinking mode from the beginning (and also try Claude, which seems very nice for coding tasks.)

1 Like

As part of the training of those LLMs, they bend over backwards trying to agree with the prompter —Gemini not so much, but you can convince ChatGPT of pretty much anything.

I remember that, as an experiment, I prompted that JSON was not a subset of YAML, simply because JSON came first. After a few round trips, ChatGPT started to agree with me, but Gemini never caved.

So, I guess the issue can go both ways —we can convince some of them that some false stuff is true, and they (by virtue of Google giving Gemini the top spot in search results) can also propagate some convincing lies.

8.5.3 ALLOCATABLE attribute

NOTE
Only variables and components can have the ALLOCATABLE attribute. The result of referencing a function whose result variable has the ALLOCATABLE attribute is a value that does not itself have the ALLOCATABLE attribute.

2 Likes