There is no segfault any more:

$ gfc pr18923.f90
 In file pr18923.f90:3

  subroutine foo(i)
               1
Error: PROGRAM attribute conflicts with PROCEDURE attribute at (1)
 In file pr18923.f90:4

    integer :: i
               1
Error: Unexpected data declaration statement in CONTAINS section at (1)
 In file pr18923.f90:5

    character(len=selected_int_kind(i)) :: c
                                           1
Error: Unexpected data declaration statement in CONTAINS section at (1)
 In file pr18923.f90:6

  end subroutine bar
    1
Error: Expecting END PROGRAM statement at (1)
 In file pr18923.f90:7

end program foo
              1
 Internal Error at (1):
 gfc_get_default_type(): Bad symbol

Fixed in 4.0.1, we no longer get an internal error:
 In file t.f:3

  subroutine foo(i)
               1
Error: PROGRAM attribute conflicts with PROCEDURE attribute at (1)
 In file t.f:4

    integer :: i
               1
Error: Unexpected data declaration statement in CONTAINS section at (1)
 In file t.f:5

    character(len=selected_int_kind(i)) :: c
                                           1
Error: Unexpected data declaration statement in CONTAINS section at (1)
 In file t.f:6

  end subroutine bar
    1
Error: Expecting END PROGRAM statement at (1)
 In file t.f:5

    character(len=selected_int_kind(i)) :: c
                 1
Error: Expression at (1) must be of INTEGER type
 In file t.f:5

    character(len=selected_int_kind(i)) :: c
                 1
Error: Expression at (1) must be of INTEGER type

With the following testcase I still get a segfault:

=================================================
module FOO
contains
    subroutine FOO
        integer :: I
        character(len=selected_int_kind(I)) :: C
    end subroutine
end
=================================================

Hmm, on powerpc-darwin built at -O0, we don't get a seg fault but on i686-pc-linux-gnu with a 
bootstrapped compiler we do.

This is no longer giving a segfault on i686-pc-linux-gnu.

 In file foo.f90:3

    subroutine FOO
                 1
Error: MODULE attribute conflicts with PROCEDURE attribute at (1)
 In file foo.f90:4

        integer :: I
                   1
Error: Unexpected data declaration statement in CONTAINS section at (1)
 In file foo.f90:5

        character(len=selected_int_kind(I)) :: C
                                               1
Error: Unexpected data declaration statement in CONTAINS section at (1)
 In file foo.f90:6

    end subroutine
      1
Error: Expecting END MODULE statement at (1)
 In file foo.f90:7

end
  1
 Internal Error at (1):
 gfc_get_default_type(): Bad symbol


Maybe this is good enough?

(In reply to comment #5)
> This is no longer giving a segfault on i686-pc-linux-gnu.
> end
>   1
>  Internal Error at (1):
>  gfc_get_default_type(): Bad symbol
> Maybe this is good enough?

There is an internal error here still.

I don't see an internal error any longer, closing as WORKSFORME.

With the following testcase I still get an internal error:

=================================================
module FOO
contains
    subroutine FOO
        integer :: I
        character(len=selected_int_kind(I)) :: C, D, E, F, G
    end subroutine
end
=================================================

 In file PR18923.f90:3

    subroutine FOO
                 1
Error: MODULE attribute conflicts with PROCEDURE attribute at (1)
 In file PR18923.f90:4

        integer :: I
                   1
Error: Unexpected data declaration statement in CONTAINS section at (1)
 In file PR18923.f90:5

        character(len=selected_int_kind(I)) :: C, D, E, F, G
                                                           1
Error: Unexpected data declaration statement in CONTAINS section at (1)
 In file PR18923.f90:6

    end subroutine
      1
Error: Expecting END MODULE statement at (1)
 In file PR18923.f90:7

end
  1
 Internal Error at (1):
 gfc_get_default_type(): Bad symbol

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

The bug reappeared on mainline. But PR 27954 did not.
So either this is not really a duplicate - or Jerry's fix was incomplete.

Jerry, would you mind having a look? Thanks!

This bug was not a duplicate of pr27954.  That was a fat fingers error that I corrected in the PR header, but I can't delete comment #9.  So as far as I know this has not been fixed yet and never was.

The testcase of comment #8 does not segfault on mainline (20070517) any more, but still does in the 4.2 branch.

Messages for mainline (note the empty names in "Error: '' at (1) is not a function"):

$> gfortran-svn -g -Wall -c pr18923.f90
pr18923.f90:3.16:

  subroutine FOO
               1
Error: MODULE attribute conflicts with PROCEDURE attribute at (1)
pr18923.f90:4.16:

    integer :: I
               1
Error: Unexpected data declaration statement in CONTAINS section at (1)
pr18923.f90:5.56:

    character(len=selected_int_kind(I)) :: C, D, E, F, G
                                                       1
Error: Unexpected data declaration statement in CONTAINS section at (1)
pr18923.f90:6.5:

  end subroutine
    1
Error: Expecting END MODULE statement at (1)
pr18923.f90:5.18:

    character(len=selected_int_kind(I)) :: C, D, E, F, G
                 1
Error: '' at (1) is not a function
pr18923.f90:5.18:

    character(len=selected_int_kind(I)) :: C, D, E, F, G
                 1
Error: '' at (1) is not a function
pr18923.f90:5.18:

    character(len=selected_int_kind(I)) :: C, D, E, F, G
                 1
Error: '' at (1) is not a function
pr18923.f90:5.18:

    character(len=selected_int_kind(I)) :: C, D, E, F, G
                 1
Error: '' at (1) is not a function
pr18923.f90:5.18:

    character(len=selected_int_kind(I)) :: C, D, E, F, G
                 1
Error: '' at (1) is not a function
pr18923.f90:5.18:

    character(len=selected_int_kind(I)) :: C, D, E, F, G
                 1
Error: Expression at (1) must be of INTEGER type



Backtrace for 4.2:
Program received signal SIGSEGV, Segmentation fault.
gfc_resolve_expr (e=0x8612478) at /home/daniel/svn/gcc-4.2/gcc/fortran/resolve.c:1751
1751            expr->ts = expr->symtree->n.sym->result->ts;
(gdb) bt
#0  gfc_resolve_expr (e=0x8612478) at /home/daniel/svn/gcc-4.2/gcc/fortran/resolve.c:1751
#1  0x08092ade in resolve_index_expr (e=0x8611160) at /home/daniel/svn/gcc-4.2/gcc/fortran/resolve.c:5362
#2  0x08092bfb in resolve_charlen (cl=<value optimized out>) at /home/daniel/svn/gcc-4.2/gcc/fortran/resolve.c:5386
#3  0x0809311f in resolve_types (ns=0x86119c0) at /home/daniel/svn/gcc-4.2/gcc/fortran/resolve.c:7255
#4  0x080930a7 in resolve_types (ns=0x8610a20) at /home/daniel/svn/gcc-4.2/gcc/fortran/resolve.c:7248
#5  0x08095e2c in gfc_resolve (ns=0x8610a20) at /home/daniel/svn/gcc-4.2/gcc/fortran/resolve.c:7311
#6  0x0808a309 in gfc_parse_file () at /home/daniel/svn/gcc-4.2/gcc/fortran/parse.c:3222
#7  0x080ac02d in gfc_be_parse_file (set_yydebug=0) at /home/daniel/svn/gcc-4.2/gcc/fortran/f95-lang.c:303
#8  0x08310faa in toplev_main (argc=2, argv=0xbf87ea84) at /home/daniel/svn/gcc-4.2/gcc/toplev.c:1033
#9  0x080d893f in main (argc=2, argv=0x1) at /home/daniel/svn/gcc-4.2/gcc/main.c:35

The testcase still crashes on mainline (and 4.1 and 4.2 branch) if I compile it without "-g" or with "--param ggc-min-expand=0 --param ggc-min-heapsize=0 -g".

Looks like there are some invalid pointers. Whether the program crashes or not
depends on the garbage they are pointing to.

Although I can not observe a crash on my machine with either flag setting, valgrind shows loads of

==32659== Invalid read of size 4
==32659==    at 0x809432F: gfc_resolve_expr (resolve.c:3220)
==32659==  Address 0x4213C2C is 20 bytes inside a block of size 24 free'd
==32659==    at 0x402119F: free (vg_replace_malloc.c:233)
==32659==    by 0x80A4D42: gfc_undo_symbols (symbol.c:1959)

in varying places, always related to gfc_undo_symbols ...

Eventually, I got a traceable segfault with this shortened testcase:

$> cat pr18923.f90
module FOO
contains
  subroutine FOO
    character(len=selected_int_kind(0)) :: C
  end subroutine
end

Program received signal SIGSEGV, Segmentation fault.
gfc_resolve_expr (e=0x887f8a8) at ../../../gcc/gcc/fortran/resolve.c:1747
1747            expr->ts = expr->symtree->n.sym->result->ts;
(gdb) bt
#0  gfc_resolve_expr (e=0x887f8a8) at ../../../gcc/gcc/fortran/resolve.c:1747
#1  0x08095bbe in resolve_index_expr (e=0x887f380) at ../../../gcc/gcc/fortran/resolve.c:5482
#2  0x08095c2f in resolve_charlen (cl=0x8845148) at ../../../gcc/gcc/fortran/resolve.c:5508
#3  0x0809746f in resolve_types (ns=0x887f020) at ../../../gcc/gcc/fortran/resolve.c:7401
#4  0x08097557 in resolve_types (ns=0x88451b0) at ../../../gcc/gcc/fortran/resolve.c:7414
#5  0x08099bfc in gfc_resolve (ns=0x88451b0) at ../../../gcc/gcc/fortran/resolve.c:7477
#6  0x0808d6ac in gfc_parse_file () at ../../../gcc/gcc/fortran/parse.c:3248
#7  0x080aeabd in gfc_be_parse_file (set_yydebug=0) at ../../../gcc/gcc/fortran/f95-lang.c:303
#8  0x082ffe68 in toplev_main (argc=2, argv=0xbf93d354) at ../../../gcc/gcc/toplev.c:1051
#9  0x080f262f in main (argc=2, argv=0x1) at ../../../gcc/gcc/main.c:35

Most notable point are the identical expressions in this if/else clause (resolve.c:1740f):
  /* Make sure that the expression has a typespec that works.  */
  if (expr->ts.type == BT_UNKNOWN)
    {
      if (expr->symtree->n.sym->result
	    && expr->symtree->n.sym->result->ts.type != BT_UNKNOWN)
	expr->ts = expr->symtree->n.sym->result->ts;
      else
	expr->ts = expr->symtree->n.sym->result->ts;       /* crashes here */
    }

Otherwise, I'm out of my wits here. Hope this helps someone?!

There is no guarantee that you are hitting the same problem, but if so, this is very helpful (sometimes :) )

Created attachment 13582 [details]
Patch to eliminate segfault

This patch eliminates the segfault from the original test case and the last test case which happen in to different places.  The first test case segfault was caused by the duplicate else clause.  That was sneaky.  I was staring at it quite a while before I noticed it.

Subject: Bug number PR18923

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01264.html

Subject: Bug 18923

Author: jvdelisle
Date: Wed May 23 04:15:25 2007
New Revision: 124979

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=124979
Log:
2007-05-22  Jerry DeLisle  <jvdelisle@gcc.gnu.org>

	PR fortran/18923
	* resolve.c (resolve_function): Don't call resolve_global_procedure if
	there is no name. Delete duplicated statement in ELSE clause.

Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/resolve.c

Subject: Bug number PR18923

A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-06/msg00111.html

Subject: Bug 18923

Author: jvdelisle
Date: Tue Jun  5 20:23:44 2007
New Revision: 125342

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125342
Log:
2007-06-05  Jerry DeLisle  <jvdelisle@gcc.gnu.org>

	PR fortran/18923
	* parse.c (decode_statement): Don't call gfc_undo_symbols on MATCH_ERROR
	for ST_FUNCTION since it is called in reject_statement.
	(parse_contained): If error, loop back after reject_statement and try
	again.  Free the namespace if an error occured.

Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/parse.c

Subject: Bug 18923

Author: jvdelisle
Date: Wed Jun  6 01:21:29 2007
New Revision: 125353

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=125353
Log:
2007-06-05  Jerry DeLisle  <jvdelisle@gcc.gnu.org>

	PR testsuite/18923
	* gfortran.dg/invalid_contains_1.f90: New test.
	* gfortran.dg/invalid_contains_2.f90: New test.

Added:
    trunk/gcc/testsuite/gfortran.dg/invalid_contains_1.f90
    trunk/gcc/testsuite/gfortran.dg/invalid_contains_2.f90
Modified:
    trunk/gcc/testsuite/ChangeLog

Fixed on trunk. Closing