https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119986
--- Comment #5 from kargls at comcast dot net --- On 4/29/25 17:01, neil.n.carlson at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119986 > > --- Comment #4 from Neil Carlson <neil.n.carlson at gmail dot com> --- > (In reply to kargls from comment #3) >> Also note, that the above generates the expected temporary arrays. > > A tangential question: Why is this expected? I would have naively thought that > a dope > vector with a stride of 2 (assuming the real and imaginary parts are > interleaved) > could have been created and passed without copying the actual array elements. > Or does > "creating array temporary" not necessarily mean data copying is occurring? Well, it's expected by me. :) gfortran has to mangle your code into something that the middle-end can digest. The real and imaginary part refs (i.e., %re and %im) map to the components of a C-centric _Complex struct. When one has an array of _Complex struct, it may be more efficient to do the copy than deal with any overhead that might arise from alignment. This is just a guess as I need to go (re)study gfortran's internals. If I compile your code with -fdump-tree-original, the call to FUBAR is translated to fubar (&x.phi, &x.phi); which confirms my guess that the issue involves passing the address of x%phi(1) for both arguments. I don't know if the middle-end can be given &x.phi(1).re and &x.phi(1).im and a 4-byte stride. The code from my example translate the call to fubar (&atmp.14, &atmp.17); where atmp.14 and atmp.17 are the temporaries.
