https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121342
--- Comment #2 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Mikael Morin <mik...@gcc.gnu.org>: https://gcc.gnu.org/g:04a1259ffea29718256beeb2aca3f473c1f259e4 commit r16-2695-g04a1259ffea29718256beeb2aca3f473c1f259e4 Author: Mikael Morin <morin-mik...@orange.fr> Date: Wed Jul 30 11:02:27 2025 +0200 fortran: Evaluate class function bounds in the scalarizer [PR121342] There is code in gfc_conv_procedure_call that, for polymorphic functions, initializes the scalarization array descriptor information and forcedfully sets loop bounds. This code is changing the decisions made by the scalarizer behind his back, and the test shows an example where the consequences are (badly) visible. In the test, for one of the actual arguments to an elemental subroutine, an offset to the loop variable is missing to access the array, as it was the one originally chosen to set the loop bounds from. This could theoretically be fixed by just clearing the array of choice for the loop bounds. This change takes instead the harder path of adding the missing information to the scalarizer's knowledge so that its decision doesn't need to be forced to something else after the fact. The array descriptor information initialisation for polymorphic functions is moved to gfc_add_loop_ss_code (after the function call generation), and the loop bounds initialization to a new function called after that. As the array chosen to set the loop bounds from is no longer forced to be the polymorphic function result, we have to let the scalarizer set a delta for polymorphic function results. For regular non-polymorphic function result arrays, they are zero-based and the temporary creation makes the loop zero-based as well, so we can continue to skip the delta calculation. In the cases where a temporary is created to store the result of the array function, the creation of the temporary shifts the loop bounds to be zero-based. As there was no delta for polymorphic result arrays, the function result descriptor offset was set to zero in that case for a zero-based array reference to be correct. Now that the scalarizer sets a delta, those forced offset updates have to go because they can make the descriptor invalid and cause erroneous array references. PR fortran/121342 gcc/fortran/ChangeLog: * trans-expr.cc (gfc_conv_subref_array_arg): Remove offset update. (gfc_conv_procedure_call): For polymorphic functions, move the scalarizer descriptor information... * trans-array.cc (gfc_add_loop_ss_code): ... here, and evaluate the bounds to fresh variables. (get_class_info_from_ss): Remove offset update. (gfc_conv_ss_startstride): Don't set a zero value for function result upper bounds. (late_set_loop_bounds): New. (gfc_conv_loop_setup): If the bounds of a function result have been set, and no other array provided loop bounds for a dimension, use the function result bounds as loop bounds for that dimension. (gfc_set_delta): Don't skip delta setting for polymorphic function results. gcc/testsuite/ChangeLog: * gfortran.dg/class_elemental_1.f90: New test.
