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!