My suspicion goes toward the fix for PR81849, so maybe also the gcc-7 and gcc-8 branches are affected.

Here is a more minimal example:
      SUBROUTINE MNREAD(IFLGIN,IFLGUT)
      IMPLICIT DOUBLE PRECISION (A-H,O-Z)
      PARAMETER (MNE=100 , MNI=50)
      PARAMETER (MNIHL=MNI*(MNI+1)/2)
      CHARACTER*10 CPNAM      
      COMMON
     1/MN7NAM/ CPNAM(MNE)
     2/MN7EXT/ U(MNE)

      CHARACTER  CRDBUF*80, CUPBUF*10
      CUPBUF(1:10) = CRDBUF(1:10)
      RETURN
      END

or also to completely implicit typing
     SUBROUTINE MNREAD(IFLGIN,IFLGUT)
      PARAMETER (MNE=100 , MNI=50)
      PARAMETER (MNIHL=MNI*(MNI+1)/2)
      CHARACTER*10 CPNAM      
      COMMON
     1/MN7NAM/ CPNAM(MNE)
     2/MN7EXT/ U(MNE)
      CHARACTER  CRDBUF*80, CUPBUF*10
      CUPBUF(1:10) = CRDBUF(1:10)
      RETURN
      END

Seems to work on the branches but I can't reproduce on trunk either.

(In reply to Richard Biener from comment #3)
> Seems to work on the branches but I can't reproduce on trunk either.

That is strange. Did you try to compile several
times? Sometimes it comes, sometimes it doesn’t.
I did svn up and compiled the gcc,
maybe I have to recompile all?

==16636== Invalid read of size 8
==16636==    at 0x93E930: resolve_ref(gfc_expr*) (resolve.c:5058)
==16636==    by 0x93FCFB: resolve_variable(gfc_expr*) (resolve.c:5536)
==16636==    by 0x942C1E: gfc_resolve_expr(gfc_expr*) (resolve.c:6852)
==16636==    by 0x94D1F0: gfc_resolve_code(gfc_code*, gfc_namespace*) (resolve.c:11283)
==16636==    by 0x95AB35: resolve_codes(gfc_namespace*) (resolve.c:16733)
==16636==    by 0x95AC5F: gfc_resolve(gfc_namespace*) (resolve.c:16768)
==16636==    by 0x92A436: resolve_all_program_units(gfc_namespace*) (parse.c:6073)
==16636==    by 0x92AC01: gfc_parse_file() (parse.c:6323)
==16636==    by 0x989C74: gfc_be_parse_file() (f95-lang.c:204)
==16636==    by 0x11F99D2: compile_file() (toplev.c:456)
==16636==    by 0x11FC4F8: do_compile() (toplev.c:2176)
==16636==    by 0x11FC7EB: toplev::main(int, char**) (toplev.c:2311)
==16636==  Address 0x519cc98 is 728 bytes inside a block of size 736 free'd
==16636==    at 0x4839A0C: free (vg_replace_malloc.c:540)
==16636==    by 0x8ABA40: gfc_free_ref_list(gfc_ref*) (expr.c:606)
==16636==    by 0x93E914: resolve_ref(gfc_expr*) (resolve.c:5082)
==16636==    by 0x93FCFB: resolve_variable(gfc_expr*) (resolve.c:5536)
==16636==    by 0x942C1E: gfc_resolve_expr(gfc_expr*) (resolve.c:6852)
==16636==    by 0x94D1F0: gfc_resolve_code(gfc_code*, gfc_namespace*) (resolve.c:11283)
==16636==    by 0x95AB35: resolve_codes(gfc_namespace*) (resolve.c:16733)
==16636==    by 0x95AC5F: gfc_resolve(gfc_namespace*) (resolve.c:16768)
==16636==    by 0x92A436: resolve_all_program_units(gfc_namespace*) (parse.c:6073)
==16636==    by 0x92AC01: gfc_parse_file() (parse.c:6323)
==16636==    by 0x989C74: gfc_be_parse_file() (f95-lang.c:204)
==16636==    by 0x11F99D2: compile_file() (toplev.c:456)
==16636==  Block was alloc'd at
==16636==    at 0x483AB1A: calloc (vg_replace_malloc.c:762)
==16636==    by 0x2194710: xcalloc (xmalloc.c:162)
==16636==    by 0x92C245: match_substring(gfc_charlen*, int, gfc_ref**, bool) (primary.c:861)
==16636==    by 0x92F18B: gfc_match_varspec(gfc_expr*, int, bool, bool) (primary.c:2428)
==16636==    by 0x932B29: match_variable(gfc_expr**, int, int) (primary.c:3977)
==16636==    by 0x932B7F: gfc_match_variable(gfc_expr**, int) (primary.c:3992)
==16636==    by 0x8EB50B: gfc_match(char const*, ...) (match.c:1165)
==16636==    by 0x8EBA5C: gfc_match_assignment() (match.c:1343)
==16636==    by 0x91D87F: match_word(char const*, match (*)(), locus*) (parse.c:65)
==16636==    by 0x91E35D: decode_statement() (parse.c:361)
==16636==    by 0x923453: next_fixed() (parse.c:1425)
==16636==    by 0x923558: next_statement() (parse.c:1473)

Could be a result of my recent commit, r267953.  I'll take a look tonight.

(In reply to Thomas Koenig from comment #6)
> Could be a result of my recent commit, r267953.  I'll take a look tonight.

That would be my guess, too,
I think it has to do with the array
descriptor together with implicit
typing and maybe together the common
block.

> My suspicion goes toward the fix for PR81849

Debugger shows

* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
    frame #0: 0x00000001000b2e1d f951`::resolve_ref(expr=0x0000000142c1c580) at resolve.c:5060
   5057	
   5058	  
   5059	  for (ref = expr->ref, prev = &expr->ref; ref; prev = &ref->next, ref = ref->next)
-> 5060	    switch (ref->type)
   5061	      {
   5062	      case REF_ARRAY:
   5063		if (!resolve_array_ref (&ref->u.ar))

so Il'd blame rather r267953.

The test gcc/testsuite/gfortran.dg/actual_array_substr_3.f90 fails at the same place.

I've confirmed this started with r267953 (running under valgrind, otherwise it doesn't reproduce for me).

Created attachment 45447 [details]
Patch that appears to work

This should fix the linked-list problem.

I'll probably submit tomorrow.

The patch in comment 10 fixes the ICEs for me. Thanks.

I can also confirm that with the provided patch our code completely compiles,
and all tests work.

Is this ready to be submitted?

(In reply to Jürgen Reuter from comment #13)
> Is this ready to be submitted?

Already done - https://gcc.gnu.org/ml/fortran/2019-01/msg00135.html .

I'll commit tomorrow unless somebody has furher to add.

Author: tkoenig
Date: Sat Jan 19 11:03:28 2019
New Revision: 268092

URL: https://gcc.gnu.org/viewcvs?rev=268092&root=gcc&view=rev
Log:
2019-01-17  Thomas Koenig  <tkoenig@gcc.gnu.org>

	PR fortran/88871
	* resolve.c (resolve_ref): Fix logic for removal of
	reference.


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

Fixed, closing.