On 2/22/24 22:01, Steve Kargl wrote:
On Thu, Feb 22, 2024 at 09:22:37PM +0100, Harald Anlauf wrote:
On the positive side, it not only seems to fix the cases in question,
but also substring references etc., like the following:
If the above passes a regression test, then by all means we should
use it. I did not consider the substring case. Even if unneeded
parentheses are inserted, which may cause generation of a temporary
variable, I hope users are not using 'allocate(x,source=z%re)' is
some deeply nested crazy loops structure.
First thing is code correctness. There are cases where the
allocation shall preserve the array bounds, which is where
we must avoid the parentheses at all cost. But these cases
should be very limited. (There are some code comments/TODOs
regarding this and an open PR by Tobias(?)).
The cases we are currently discussing are even requiring(!)
the resetting of the lower bounds to 1, so your suggestion
to enforce parentheses does not look unreasonable.
BTW: If someone uses allocate in a tight loop, he/she deserves
to be punished anyway...
BTW, my patch and I suspect your improved patch also
fixes 'allocate(x,mold=z%re)'. Consider,
complex z(3)
real, allocatable :: x(:)
z = 42ha
allocate(x, mold=z%re)
print *, size(x)
end
% gfortran13 -o z a.f90
a.f90:9:25:
9 | allocate(x, mold=z%re)
| 1
internal compiler error: in retrieve_last_ref, at fortran/trans-array.cc:6070
0x247d7a679 __libc_start1
/usr/src/lib/libc/csu/libc_start1.c:157
% gfcx -o z a.f90 && ./z
3
Nice! I completely forgot about MOLD...
So the only missing pieces are a really comprehensive testcase
and successful regtests...
Cheers,
Harald
