https://gcc.gnu.org/bugzilla/show_bug.cgi?id=128033
--- Comment #5 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The trunk branch has been updated by Mikael Morin <[email protected]>: https://gcc.gnu.org/g:e9a6d9dee3098bc32d7b5da750a65755fea7a734 commit r17-5758-ge9a6d9dee3098bc32d7b5da750a65755fea7a734 Author: Mikael Morin <[email protected]> Date: Fri Oct 30 14:33:34 2026 +0100 fortran: Fix copy from polymorphic pointer source in ALLOCATE [PR128033] Fix two problems relating to the source argument of ALLOCATE statements. When the source is a pointer array, drop the forced temporary leading to a bogus copy, and to avoid regressing when the source is an array subreference, fix the retrieval of the array reference serving as source of bounds. To fix PR114024, r14-9160 introduced an automatic wrapping in parentheses of the allocate source expression, forcing the generation of a temporary and avoiding an internal error. That change causes a regression with polymorphic pointers, because the reference generated for the temporary array doesn't contain the class container as parent subreference, so the array indexing ends up being generated by the non-polymorphic fall back. As a consequence, indexing is off and the values copied are wrong. This change reverts that PR114024 fix. It doesn't solve the underlying problem in case the parentheses are explicitly present in the user code, but it at least fixes the much more common case where they are absent. Reverting means restoring the original problem which has to be fixed some other way. The problem is an assertion failure expecting all intermediary array references to be single element references in the walk to find the last element of the data reference chain. The assertion makes sense in the context of the allocated entity, but the same function is also used with the source expression as input. In the latter case, there can be subreferences coming after the main array reference, so it's not a surprise that the assertion triggers. In the first place, we shouldn't be looking for the last element in the reference chain, as there is no guarantee that is the one holding the array information. To fix this, we need to find the single non-element array reference in the chain of the source expression. There is the existing gfc_find_array_ref which does exactly that, except it returns a gfc_array_ref, not a gfc_ref. So the type of the main array ref pointer is changed from gfc_ref to gfc_array_ref, and all the accesses from the gfc_ref to the gfc_array_ref beneath it are factored to set the new pointer. PR fortran/114024 PR fortran/128033 gcc/fortran/ChangeLog: * trans-stmt.cc (gfc_trans_allocate): Remove automatic wrapping of array subreferences in a parentheses expression. * trans-array.cc (gfc_array_allocate): Find the single non-element array reference in the source expression instead of getting the last reference in the chain. Use a gfc_array_ref pointer instead of a gfc_ref pointer and simplify the references using it. gcc/testsuite/ChangeLog: * gfortran.dg/allocate_with_source_34.f90: New test.
