I have retested a clean tree with only the patches for pr 65792 [first patch] and Andre’s one for pr59678: i.e., without any patch from pr61831, and I still see the conflict between the two patches.
Dominique > Le 19 avr. 2015 à 10:39, Dominique d'Humières <domi...@lps.ens.fr> a écrit : > >> Snip >> Both patches have been regression tested on trunk on x86_64-linux. >> >> OK for trunk [first patch]? >> OK for 4.9 and 5 (after the 5.1 release) [second patch]? >> >> Mikael >> >> PS: Dominiq reported that the variant of this patch posted on the PR was >> also fixing PR49324. I couldn't confirm as what seems to be the >> remaining testcase there (comment #6) doesn't fail with trunk here. > > I have tested both patches on my working tree and on a clean one, but only on > top of the [better patch] for pr61831, without the hunk > > @@ -4990,7 +5010,7 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * > > tmp = gfc_deallocate_alloc_comp (e->ts.u.derived, tmp, parm_rank); > > - gfc_add_expr_to_block (&se->post, tmp); > + gfc_prepend_expr_to_block (&se->post, tmp); > } > > /* Add argument checking of passing an unallocated/NULL actual to > > > as said in pr61831 comment 45 (the above hunk causes a regression for > gfortran.dg/alloc_comp_assign_10.f90). > > AFAICT this is the [better patch] which fixes PR49324. > > Now Andre Vehreschild has submitted a patch for pr59678 at > https://gcc.gnu.org/ml/fortran/2015-04/msg00061.html. Andre's patch works > well with the [second patch]+[better patch], but leads to a regression for > gfortran.dg/class_19.f03 (pr65792 comment 3) with the [first patch]+[better > patch]. So if the [first patch] is chosen, it will require some change(s) in > Andre’s patch. > > Thanks for working on these issues, > > Dominique >
