With gfortran 4.9.0 (r201776) the following causes an incorrect warning message to be issued: module ct type :: a contains final :: aD end type a contains subroutine aD(self) type(a), intent(inout) :: self end subroutine aD end module ct program test use ct end program test $ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-trunk/configure --prefix=/home/abenson/Galacticus/Tools --enable-languages=c,c++,fortran --disable-multilib --with-gmp=/home/abenson/Galacticus/Tools Thread model: posix gcc version 4.9.0 20130815 (experimental) (GCC) $ gfortran -c bug1.F90 -o bug1.o -Wall bug1.F90:12.6: use ct 1 Warning: Only array FINAL procedures declared for derived type 'a' defined at (1), suggest also scalar one bug1.F90:7.20: subroutine aD(self) 1 Warning: Unused dummy argument 'self' at (1) Only a scalar finalizor is present, but the warning suggests that an array but no scalar finalizor is present. The warning is only issued if the "ct" module is USEd. Adding an array finalizor or making the scalar finalizor ELEMENTAL does not change the warning message.
Untested patch. (The second part just makes use of the following existing line: my_rank = (arg->as ? arg->as->rank : 0); ) diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c index 067288d..28321bb 100644 --- a/gcc/fortran/resolve.c +++ b/gcc/fortran/resolve.c @@ -11124,6 +11124,9 @@ gfc_resolve_finalizers (gfc_symbol* derived) /* Skip this finalizer if we already resolved it. */ if (list->proc_tree) { + if (list->proc_tree->n.sym->formal->sym->as == NULL + || list->proc_tree->n.sym->formal->sym->as->rank == 0) + seen_scalar = true; prev_link = &(list->next); continue; } @@ -11217,7 +11220,7 @@ gfc_resolve_finalizers (gfc_symbol* derived) } /* Is this the/a scalar finalizer procedure? */ - if (!arg->as || arg->as->rank == 0) + if (my_rank == 0) seen_scalar = true; /* Find the symtree for this procedure. */
(In reply to Tobias Burnus from comment #1) > Untested patch. ... indeed seems to fix the problem.
(In reply to Tobias Burnus from comment #1) > Untested patch. Any ambitions to commit this?
I still have this bug in 4.9.2 . Why not committing the patch ?
This bug still exists in fortran 5.1.0 (released version). My testcase ended up being a duplicate of the original post, so I won't repost that. % gfortran -Wall -o final_bug_2 final_bug_2.f90 final_bug_2.f90:13:6: use A 1 Warning: Only array FINAL procedures declared for derived type ‘typea’ defined at (1), suggest also scalar one [-Wsurprising] % gfortran -v Using built-in specs. COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/5.1.0/gfortran COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/5.1.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-5.1.0/work/gcc-5.1.0/configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/5.1.0 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/5.1.0/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/5.1.0 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/5.1.0/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/5.1.0/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/5.1.0/include/g++-v5 --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/5.1.0/python --enable-objc-gc --enable-languages=c,c++,java,go,objc,obj-c++,fortran --enable-obsolete --enable-secureplt --disable-werror --with-system-zlib --enable-nls --without-included-gettext --enable-checking=release --with-bugurl=https://bugs.gentoo.org/ --with-pkgversion='Gentoo 5.1.0 p1.0, pie-0.6.3' --enable-libstdcxx-time --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-multilib --with-multilib-list=m32,m64 --disable-altivec --disable-fixed-point --enable-targets=all --enable-libgomp --disable-libmudflap --disable-libssp --enable-libcilkrts --enable-lto --with-isl --disable-isl-version-check --enable-libsanitizer Thread model: posix gcc version 5.1.0 (Gentoo 5.1.0 p1.0, pie-0.6.3)
This problem still occurs in gcc 6.0.0. In a code which makes extensive use of finalizors it results in many thousands of erroneous warning messages during compile, which have to be filtered out to find the real warnings. Is there any way I can help get the proposed patch committed (e.g. maybe testing it to ensure it introduces no regressions)?
*** Bug 66291 has been marked as a duplicate of this bug. ***
*** Bug 70312 has been marked as a duplicate of this bug. ***
Still present in 6.1.1, please fix.
> Still present in 6.1.1, please fix. You're welcome to do it!
It looks like there's already a patch there, if you point me at a list of what needs doing to get it into the code base, I'm happy to take a look. Thanks, Jonathan. On Thu, Jul 7, 2016 at 4:14 PM, dominiq at lps dot ens.fr < gcc-bugzilla@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58175 > > --- Comment #10 from Dominique d'Humieres <dominiq at lps dot ens.fr> --- > > Still present in 6.1.1, please fix. > > You're welcome to do it! > > -- > You are receiving this mail because: > You are on the CC list for the bug.
The patch in comment #1 still works and regtests fine. I'll take care of committing it ...
Author: janus Date: Tue Nov 29 14:15:29 2016 New Revision: 242960 URL: https://gcc.gnu.org/viewcvs?rev=242960&root=gcc&view=rev Log: 2016-11-29 Tobias Burnus <burnus@net-b.de> PR fortran/58175 * resolve.c (gfc_resolve_finalizers): Properly detect scalar finalizers. 2016-11-29 Janus Weil <janus@gcc.gnu.org> PR fortran/58175 * gfortran.dg/finalize_30.f90: New test case. Added: trunk/gcc/testsuite/gfortran.dg/finalize_30.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
Fixed with r242960. Closing.
Hi Janus, The patch fixes most cases but, when compiling my full code I found some cases which still report the erroneous warning. These seem to be with cases where a derived type extends another derived type. For example, with gfortran 7.0.0 (r 242964) the following occurs: module ct type :: a contains final :: aD end type a type, extends(a) :: a1 contains end type a1 contains subroutine aD(self) type(a), intent(inout) :: self end subroutine aD end module ct program test use ct end program test $ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-trunk/configure --prefix=/home/abenson/Galacticus/Tools --enable-languages=c,c++,fortran --disable-multilib Thread model: posix gcc version 7.0.0 20161129 (experimental) (GCC) $ gfortran -c bug.F90 -o bug.o -Wall bug.F90:7:24: type, extends(a) :: a1 1 Warning: Only array FINAL procedures declared for derived type 'a1' defined at (1), suggest also scalar one [-Wsurprising] bug.F90:16:6: use ct 1 Warning: Only array FINAL procedures declared for derived type 'a1' defined at (1), suggest also scalar one [-Wsurprising] bug.F90:11:20: subroutine aD(self) 1 Warning: Unused dummy argument 'self' at (1) [-Wunused-dummy-argument] So, there's no warning about the finalizer for type "a", but for type "a1" there's still a warning present.
Author: janus Date: Sat Dec 3 09:32:27 2016 New Revision: 243218 URL: https://gcc.gnu.org/viewcvs?rev=243218&root=gcc&view=rev Log: 2016-12-03 Janus Weil <janus@gcc.gnu.org> PR fortran/58175 * resolve.c (gfc_resolve_finalizers): Prevent bogus warning. 2016-12-03 Janus Weil <janus@gcc.gnu.org> PR fortran/58175 * gfortran.dg/finalize_30.f90: Extend test case. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/finalize_30.f90
(In reply to Andrew Benson from comment #15) > The patch fixes most cases but, when compiling my full code I found some > cases which still report the erroneous warning. Thanks for reporting, Andrew. I have just committed a minor addition in r243218 that fixes this case as well, so that we can finally close this PR.
Thanks Janus. I can confirm that I see no more of these warnings now!