Hi Paul, the patch looks fine to me. I assume you have regtested it? (Because you don't state so.)
Thanks for the patch. - Andre On Wed, 27 Nov 2024 08:57:25 +0000 Paul Richard Thomas <paul.richard.tho...@gmail.com> wrote: > Hi All, > > The "fix" for PR84674 caused this regression. > > The diagnostics that I had used for PR117763 allowed me to find a much > better fix for PR84674 and so this patch reverts the chunk in resolve.cc. > > The chunk in class.cc works because non_overridable typebound procedures, > whose parent is abstract, do not have the 'overridden' field set. This > caused an immediate return from 'add_proc_comp' and this led to viable > typebound procedures being rejected. The fix checks the vtype component for > a specific typebound procedure that is abstract and uses this to suppress > the immediate return. I tested not adding the initialization expression if > the specific is abstract but, although this version regression tested OK, > decided to keep the patch as minimal as possible. > > OK for mainline and, after a decent interval, to backport the chunk in > class.cc to the branches affected by PR84674? > > Regards > > Paul > > Fortran: Fix non_overridable typebound proc problems [PR84674/117768]. > > 2024-11-27 Paul Thomas <pa...@gcc.gnu.org> > > gcc/fortran/ChangeLog > > PR fortran/84674 > * class.cc (add_proc_comp): If the component points to a tbp > that is abstract, do not return since the new version is more > likely to be usable. > PR fortran/117768 > * resolve.cc (resolve_fl_derived): Remove the condition that > rejected a completely empty derived type extension. > > gcc/testsuite/ChangeLog > > PR fortran/117768 > * gfortran.dg/pr117768.f90: New test. -- Andre Vehreschild * Email: vehre ad gmx dot de
