This is rather easily fixed, I suspect:

if (sym->attr.dummy && sym->attr.if_source == IFSRC_DECL)
  {
    ...error...
  }

in resolve.c should do the job.  Just have to find the right place!

Confirmed

Paul

The same ICE is triggered by 

subroutine s
contains
  SUBROUTINE s	
  END SUBROUTINE
end subroutine

This goes off at a tangent, but still related to this PR ...

I think this is valid as the RESULT f is in the scope of g only and shadows the FUNCTION f (Lahey accepts it):

FUNCTION f()
contains
  FUNCTION g() RESULT(f)
  END FUNCTION
END FUNCTION


But what's going on here?
FUNCTION f() RESULT(g)
contains
  FUNCTION g()
  END FUNCTION
END FUNCTION

$ gfortran-svn pr44348.f90 
pr44348.f90: In function 'f':
pr44348.f90:4:0: error: aggregate value used where a float was expected

Lahey says:
1723-S: "SOURCE.F90", line 3, column 12: 'g' already used as a variable name.

The patch below fixes the ICE in comment #2, but not the original report.

However, it also message-regresses on
FAIL: gfortran.dg/derived_function_interface_1.f90  -O   (test for errors, line 41)
FAIL: gfortran.dg/derived_function_interface_1.f90  -O   (test for errors, line 42)
FAIL: gfortran.dg/global_references_1.f90  -O  (test for excess errors)


Index: decl.c
===================================================================
--- decl.c      (revision 160638)
+++ decl.c      (working copy)
@@ -863,7 +863,6 @@ get_proc_name (const char *name, gfc_sym
         this is handled using gsymbols to register unique,globally
         accessible names.  */
       if (sym->attr.flavor != 0
-         && sym->attr.proc != 0
          && (sym->attr.subroutine || sym->attr.function)
          && sym->attr.if_source != IFSRC_UNKNOWN)
        gfc_error_now ("Procedure '%s' at %C is already defined at %L",

I still have the same bug on gfortran 4.8.0.
And a tree check if gfortran built with -fsanitize.

Still there in 4.8.2
gfbug5.f: In function ‘ff’:
gfbug5.f:3:0: internal compiler error: in make_decl_rtl, at varasm.c:1140
       subroutine sub(ff)
 ^
0x9fd8c2 make_decl_rtl(tree_node*)
	../../gcc-4.8.2/gcc/varasm.c:1139
0x5a6ff6 trans_function_start
	../../gcc-4.8.2/gcc/fortran/trans-decl.c:2293
0x5aee10 gfc_generate_function_code(gfc_namespace*)
	../../gcc-4.8.2/gcc/fortran/trans-decl.c:5307
0x5af017 gfc_generate_contained_functions
	../../gcc-4.8.2/gcc/fortran/trans-decl.c:4530
0x5af017 gfc_generate_function_code(gfc_namespace*)
	../../gcc-4.8.2/gcc/fortran/trans-decl.c:5333
0x552a20 translate_all_program_units
	../../gcc-4.8.2/gcc/fortran/parse.c:4474
0x552a20 gfc_parse_file()
	../../gcc-4.8.2/gcc/fortran/parse.c:4688
0x58e195 gfc_be_parse_file
	../../gcc-4.8.2/gcc/fortran/f95-lang.c:189

Current status:

Original report is fixed.
 
GNU Fortran (GCC) 6.0.0 20150811 (experimental)

[bdavis@linux1 ~/gcc]$ cat a.f
      subroutine sub(ff)
      contains
      subroutine ff
      end subroutine
      end
[bdavis@linux1 ~/gcc]$ ./run/bin/gfortran a.f
a.f:3:72:

Error: internal procedure 'ff' at (1) conflicts with DUMMY argument

From comment #2, still broken

[bdavis@linux1 ~/gcc]$ cat b.f
       subroutine s
       contains
         SUBROUTINE s  
         END SUBROUTINE
       end subroutine
[bdavis@linux1 ~/gcc]$ ./run/bin/gfortran b.f
b.f:3:0:

          SUBROUTINE s  
1
internal compiler error: in gfc_generate_function_code, at fortran/trans-decl.c:5781
0x6e7ff0 gfc_generate_function_code(gfc_namespace*)
	../../current/gcc/fortran/trans-decl.c:5781
0x6e5f37 gfc_generate_contained_functions
	../../current/gcc/fortran/trans-decl.c:5038
0x6e5f37 gfc_generate_function_code(gfc_namespace*)
	../../current/gcc/fortran/trans-decl.c:5824
0x673490 translate_all_program_units
	../../current/gcc/fortran/parse.c:5521
0x673490 gfc_parse_file()
	../../current/gcc/fortran/parse.c:5726
0x6b4d22 gfc_be_parse_file
	../../current/gcc/fortran/f95-lang.c:209
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

      subroutine s
       contains
         SUBROUTINE s  
         END SUBROUTINE
       end subroutine

q?  Is this valid ?

No, it is not valid, but gfortran should signal this with an error message.
Not with a crash.

*** Bug 66494 has been marked as a duplicate of this bug. ***

As a side note, with a slightly modified example b from comment 3 and

$ gfortran --version
GNU Fortran (SUSE Linux) 5.2.1 20151008 [gcc-5-branch revision 228597]


$ cat pr44348_c3b_modified.f90
FUNCTION f2() RESULT(g)
  real :: g
contains
  real FUNCTION g()
  END FUNCTION
END FUNCTION


$ gfortran -g -O0 -Wall -fcheck=all pr44348_c3b_modified.f90
pr44348_c3b_modified.f90:4.17:

  real FUNCTION g()
                 1
pr44348_c3b_modified.f90:1.23:

FUNCTION f2() RESULT(g)
                       2
Error: Procedure 'g' at (1) has an explicit interface and must not have attributes declared at (2)

f951: internal compiler error: Segmentation fault


---

With gfortran 4.9.0 :

$ gfortran-4.9 -g -O0 -Wall -fcheck=all pr44348_c3b_modified.f90
pr44348_c3b_modified.f90:4.17:

  real FUNCTION g()
                 1
pr44348_c3b_modified.f90:1.23:

FUNCTION f2() RESULT(g)
                       2
Error: Procedure 'g' at (1) has an explicit interface and must not have attributes declared at (2)
pr44348_c3b_modified.f90:4.19:

  real FUNCTION g()
                   1
Error: Symbol 'g' at (1) already has basic type of REAL
pr44348_c3b_modified.f90:6.3:

END FUNCTION
   1
Error: Expecting END PROGRAM statement at (1)

Slightly modified variant :


$ cat z7.f90
subroutine s(x)
contains
   subroutine s(x)
   end
end


$ gfortran-7-20160828 z7.f90
z7.f90:3:0:

    subroutine s(x)

internal compiler error: in gfc_generate_function_code, at fortran/trans-decl.c:6100
0x751496 gfc_generate_function_code(gfc_namespace*)
        ../../gcc/fortran/trans-decl.c:6100
0x74f357 gfc_generate_contained_functions
        ../../gcc/fortran/trans-decl.c:5194
0x74f357 gfc_generate_function_code(gfc_namespace*)
        ../../gcc/fortran/trans-decl.c:6143
0x6db090 translate_all_program_units
        ../../gcc/fortran/parse.c:5910
0x6db090 gfc_parse_file()
        ../../gcc/fortran/parse.c:6116
0x71d3a2 gfc_be_parse_file
        ../../gcc/fortran/f95-lang.c:198

The test in comment 2 compiles without error at revision r242002
although I think it is invalid. It gives an ICE with r241962.

> The test in comment 2 compiles without error at revision r242002
> although I think it is invalid. It gives an ICE with r241962.

This is due to r241972 (pr77596).

(In reply to Dominique d'Humieres from comment #14)
> > The test in comment 2 compiles without error at revision r242002
> > although I think it is invalid. It gives an ICE with r241962.
> 
> This is due to r241972 (pr77596).

Huh, I don't see how r241972 (which only deals with pointer assignments) could affect comment 2.

I see it ICEing with r242047, as it did with previous releases:

internal compiler error: in gfc_generate_function_code, at fortran/trans-decl.c:6147
0x90a75b gfc_generate_function_code(gfc_namespace*)
	/home/jweil/gcc/gcc7/trunk/gcc/fortran/trans-decl.c:6147
0x90802b gfc_generate_contained_functions
	/home/jweil/gcc/gcc7/trunk/gcc/fortran/trans-decl.c:5241
0x90a92e gfc_generate_function_code(gfc_namespace*)
	/home/jweil/gcc/gcc7/trunk/gcc/fortran/trans-decl.c:6190
0x8cdab7 gfc_generate_code(gfc_namespace*)
	/home/jweil/gcc/gcc7/trunk/gcc/fortran/trans.c:2030
0x85cceb translate_all_program_units
	/home/jweil/gcc/gcc7/trunk/gcc/fortran/parse.c:6038
0x85d360 gfc_parse_file()
	/home/jweil/gcc/gcc7/trunk/gcc/fortran/parse.c:6238
0x8b645f gfc_be_parse_file
	/home/jweil/gcc/gcc7/trunk/gcc/fortran/f95-lang.c:202

> Huh, I don't see how r241972 (which only deals with pointer assignments)
> could affect comment 2.
>
> I see it ICEing with r242047, as it did with previous releases: ...

I am just reporting what I see:

[Book15] f90/bug% /opt/gcc/gcc7p-241962p4/bin/gfortran -c pr44348_1.f90
pr44348_1.f90:3:0:

   SUBROUTINE s
 
internal compiler error: in gfc_generate_function_code, at fortran/trans-decl.c:6144

pr44348_1.f90:3:0: internal compiler error: Abort trap: 6
gfortran: internal compiler error: Abort trap: 6 (program f951)
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
[Book15] f90/bug% /opt/gcc/gcc7p-241972p4/bin/gfortran -c pr44348_1.f90
[Book15] f90/bug%

(In reply to Dominique d'Humieres from comment #16)
> > Huh, I don't see how r241972 (which only deals with pointer assignments)
> > could affect comment 2.
> >
> > I see it ICEing with r242047, as it did with previous releases: ...
> 
> I am just reporting what I see:
>  
> internal compiler error: in gfc_generate_function_code, at
> fortran/trans-decl.c:6144

I do buy that. As mentioned I also see the same ICE.

But your previous message seems to suggest that the ICE is gone on trunk. This I cannot confirm. And I cannot imagine how my commit would cause that ...

> But your previous message seems to suggest that the ICE is gone on trunk.
> This I cannot confirm. And I cannot imagine how my commit would cause that ...

You missed:

[Book15] f90/bug% /opt/gcc/gcc7p-241972p4/bin/gfortran -c pr44348_1.f90
[Book15] f90/bug%

I also see it with my latest build (r242058)

[Book15] f90/bug% gfc -c pr44348_1.f90
[Book15] f90/bug%

(In reply to Dominique d'Humieres from comment #18)
> I also see it with my latest build (r242058)
> 
> [Book15] f90/bug% gfc -c pr44348_1.f90
> [Book15] f90/bug%

I cannot confirm that. I do see the ICE on comment 2 at r242066.

> I cannot confirm that. I do see the ICE on comment 2 at r242066.

OK. I have "recovered" the ICE with the patch at https://gcc.gnu.org/ml/gcc-patches/2016-11/msg01045.html (pr78267). AFAICT the ICE is replaced by accept-invalid when gcc is configured with --disable-libsanitizer or with the patch in pr78267 comment 15.

I did not encounter any ICE with the test cases in this PR which I tried.
Have they been fixed by Steve's recent patch?

(In reply to Harald Anlauf from comment #21)
> I did not encounter any ICE with the test cases in this PR which I tried.
> Have they been fixed by Steve's recent patch?

Yes, at least for comment #2 and #12.  It is a duplicate PR77414.

(In reply to kargl from comment #22)
> (In reply to Harald Anlauf from comment #21)
> > I did not encounter any ICE with the test cases in this PR which I tried.
> > Have they been fixed by Steve's recent patch?
> 
> Yes, at least for comment #2 and #12.  It is a duplicate PR77414.

The code in comment 1 was fixed by 

r223313 | kargl | 2015-05-18 12:25:49 -0700 (Mon, 18 May 2015) | 11 lines

2015-05-18  Steven G. Kargl  <kargl@gcc.gnu.org>

        PR fortran/64925
        * symbol.c(check_conflict):  Check for a conflict between a dummy
        argument and an internal procedure name.

2015-05-18  Steven G. Kargl  <kargl@gcc.gnu.org>

        PR fortran/64925
        * gfortran.dg/pr64925.f90: New test.

*** This bug has been marked as a duplicate of bug 64925 ***