Hi Mikael, Thank you for the review and, in particular, the corrections in the fortran ChangeLog. Unfortunately, both of us missed the systematically wrong PR number. The commit was made to 15-branch with the wrong number throughout, which I will correct tomorrow. This, however, has made a bit more work for Jakub, which I have communicated to him through the PR. It is what comes of working in a hurry, late at night.
The good news is that it fixes the original problem, which showed up in Parallel Sparse BLAS is fixed. Best regards Paul On Mon, 29 Apr 2024 at 09:34, Mikael Morin <morin-mik...@orange.fr> wrote: > Hello, > > Le 28/04/2024 à 23:37, Paul Richard Thomas a écrit : > > Hi All, > > > > Could this be looked at quickly? The timing of this regression is more > > than a little embarrassing on the eve of the 14.1 release. The testcase > > and the comment in gfc_trans_class_init_assign explain what this problem > > is all about and how the patch fixes it. > > > > OK for 15-branch and backporting to 14-branch (hopefully to the RC as > well)? > > > > Paul > > > > Fortran: Fix regression caused by r14-9752 [PR114959] > > > > 2024-04-28 Paul Thomas <pa...@gcc.gnu.org <mailto:pa...@gcc.gnu.org>> > > You can drop the mailto:… thing. ;-) > > > gcc/fortran > > PR fortran/114959 > > * trans-expr.cc (gfc_trans_class_init_assign): Return NULL_TREE > > if the default initializer has all NULL fields. Guard this > > by a requirement that the code be EXEC_INIT_ASSIGN and that the > > object be an INTENT_IN dummy. > > In the patch, the code requirement is different from EXEC_ALLOCATE and > the intent is INTENT_OUT, not INTENT_IN. > > > * trans-stmt.cc (gfc_trans_allocate): Change the initializer > > code for allocate with mold to EXEC_ASSIGN to allow initializer > > with all NULL fields.. > > In the patch it's EXEC_ALLOCATE, not EXEC_ASSIGN. > > OK for master with the ChangeLog fixed. > For 14, you need release manager approval, I think. > Thanks for the quick fix. > > Mikael >
