All releases starting from 4.8.0 ICE. Before that:

  4.7.4 (ae10eb82fe34c186)(12 Jun 2014 12:08): [took: 0.019s] result: FAILED
pr79072.f90:2.10:

  class(*), pointer :: foo
          1
Fatal Error: Unlimited polymorphism at (1) not yet supported

IMO bugs in new features are not regressions.

Why is this tagged with 'ice-on-invalid-code'?  What is invalid about the code?

Sorry, bug description fixed.

Here's a more complete example that avoids the ICE.

It gives correct results with 6.3:
           5 fubar
           5 fubar

But incorrect results with 7.0:
           5 fubar
           0 


program main

  class(*), pointer :: x, y
  allocate(x, source='fubar')
  
  y => foobar(x)
  
  select type (y)
  type is (character(*))
    print *, len(y), y
  end select

contains

  function foobar(bar) result(foo)
    class(*), pointer :: foo, bar
    foo => bar
    select type (foo)
    type is (character(*))
      print *, len(foo), foo
    end select
  end function

end program

Comment 1 code example segfaults with the 7.1.0 release (and earlier).

Comment 5 code example gives incorrect results with the 7.1.0 release,
but correct results with 6.3 and 5.2 -- a regression.

> Comment 5 code example gives incorrect results with the 7.1.0 release,
> but correct results with 6.3 and 5.2 -- a regression.

Likely caused by revision r241439. AFAICT this could be two different PRs.

Redoing https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01290.html which was lost:

--- Comment #8 from neil.n.carlson at gmail dot com ---
Ping.  Is there any interest in fixing this regression?

(In reply to Eric Gallager from comment #8)
> Redoing https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01290.html which was lost:
> 
> --- Comment #8 from neil.n.carlson at gmail dot com ---
> Ping.  Is there any interest in fixing this regression?

Yes, anything that is a failure on valid code we want to fix. We are simply very short handed. What is the pain level on this one?

I happened upon this bug in the course of fixing PR78990. It looked at first sight to be similar but is not.... of course. However, the fix was real easy and I'll submit it a bit later on.

Thanks for the report and sorry that it is taken so long.

Paul

Paul, I'm organizing all my bug report examples, and ran across these two test cases from September that I can't find I ever reported.  They are VERY similar to the original example I posted, except the ICE occurs in a different file, so I thought I'd add them here.  I can submit a separate PR if you think it more appropriate.

The first compiles on 6.4.1, 7.2.1, and 8.0.0 (20171028). But produces an incorrect result:

b="" (expect "foo")

character(3), target :: a = 'foo'
class(*), pointer :: b
b => ptr()
select type (b)
type is (character(*))
  print '(3a)', 'b="', b, '" (expect "foo")'
end select
contains
  function ptr()
    class(*), pointer :: ptr
    ptr => a
  end function
end

The second adds a select case and print to get at the result value before its handed back.  This produces an ICE with 6.4.1, 7.2.1, and 8.0.0 (20171028)

character(3), target :: a = 'foo'
class(*), pointer :: b
b => ptr()
select type (b)
type is (character(*))
  print '(3a)', 'b="', b, '" (expect "foo")'
end select
contains
  function ptr()
    class(*), pointer :: ptr
    ptr => a
    select type (ptr)
    type is (character(*))
    end select
  end function
end

Here's the traceback on 7.2.1:

gfortran-bug-20170812b.f90:46:0:

 character(3), target :: a = 'foo'
 
internal compiler error: in gfc_advance_chain, at fortran/trans.c:58
0x65d137 gfc_advance_chain(tree_node*, int)
	../../gcc/fortran/trans.c:58
0x685eba gfc_class_len_get(tree_node*)
	../../gcc/fortran/trans-expr.c:226
0x6c6364 trans_associate_var
	../../gcc/fortran/trans-stmt.c:1778
0x6c6364 gfc_trans_block_construct(gfc_code*)
	../../gcc/fortran/trans-stmt.c:1831
0x65d6b7 trans_code
	../../gcc/fortran/trans.c:1913
0x6c77d9 gfc_trans_select_type_cases
	../../gcc/fortran/trans-stmt.c:2422
0x6c77d9 gfc_trans_select_type(gfc_code*)
	../../gcc/fortran/trans-stmt.c:3133
0x65d747 trans_code
	../../gcc/fortran/trans.c:1933
0x6c5e38 gfc_trans_block_construct(gfc_code*)
	../../gcc/fortran/trans-stmt.c:1824
0x65d6b7 trans_code
	../../gcc/fortran/trans.c:1913
0x682847 gfc_generate_function_code(gfc_namespace*)
	../../gcc/fortran/trans-decl.c:6332
0x682634 gfc_generate_contained_functions
	../../gcc/fortran/trans-decl.c:5327
0x682634 gfc_generate_function_code(gfc_namespace*)
	../../gcc/fortran/trans-decl.c:6261
0x616eb6 translate_all_program_units
	../../gcc/fortran/parse.c:6074
0x616eb6 gfc_parse_file()
	../../gcc/fortran/parse.c:6274
0x65a02f gfc_be_parse_file
	../../gcc/fortran/f95-lang.c:204

Correction to Comment 11.  That example gives the *correct* result on 6.4.1

The patch at https://gcc.gnu.org/ml/fortran/2017-11/msg00103.html fixes gfortran for the tests in comment 0, 5 and 11, but not for the test in comment 12:

internal compiler error: tree check: expected record_type or union_type or qual_union_type, have function_type in gfc_class_len_get, at fortran/trans-expr.c:226

Author: pault
Date: Mon Nov 20 19:09:34 2017
New Revision: 254966

URL: https://gcc.gnu.org/viewcvs?rev=254966&root=gcc&view=rev
Log:
2017-11-20  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/79072
	* trans-expr.c (trans_class_vptr_len_assignment): Set from_len
	if the temporary is unlimited polymorphic.
	* trans-stmt.c (trans_associate_var): Use the fake result decl
	to obtain the 'len' field from an explicit function result when
	in that function scope.

2017-11-20  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/79072
	* gfortran.dg/class_result_5.f90: New test.


Added:
    trunk/gcc/testsuite/gfortran.dg/class_result_5.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-expr.c
    trunk/gcc/fortran/trans-stmt.c
    trunk/gcc/testsuite/ChangeLog

I've confirmed Dominique's findings: Code in comments 0, 5, 11 are working now with Paul's commit (Thanks!), but comment 12 code still gives an ICE.

Should I create a new PR for that example, or is it fine leaving this PR open?

(In reply to neil.n.carlson from comment #16)
> I've confirmed Dominique's findings: Code in comments 0, 5, 11 are working
> now with Paul's commit (Thanks!), but comment 12 code still gives an ICE.
> 
> Should I create a new PR for that example, or is it fine leaving this PR
> open?

Leave it open, thanks. Dominique, reminded me of the comment.

Paul

Author: pault
Date: Wed Nov 22 11:37:16 2017
New Revision: 255053

URL: https://gcc.gnu.org/viewcvs?rev=255053&root=gcc&view=rev
Log:
2017-11-22  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/79072
	* trans-stmt.c (trans_associate_var): Weaken the over strong
	condition for using the fake result decl.

2017-11-22  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/79072
	* gfortran.dg/class_result_6.f90: New test for comment 10 of
	the PR.


Added:
    trunk/gcc/testsuite/gfortran.dg/class_result_6.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-stmt.c
    trunk/gcc/testsuite/ChangeLog

This fixes the code of comment 12 for me.  All the other test cases continue to work as expected.  This can be closed as "fixed" as far as I'm concerned. Thanks Paul!

Author: pault
Date: Thu Nov 23 21:02:48 2017
New Revision: 255120

URL: https://gcc.gnu.org/viewcvs?rev=255120&root=gcc&view=rev
Log:
2017-11-23  Paul Thomas  <pault@gcc.gnu.org>


	Backported from trunk
	PR fortran/79072
	* trans-expr.c (trans_class_vptr_len_assignment): Set from_len
	if the temporary is unlimited polymorphic.
	* trans-stmt.c (trans_associate_var): Use the fake result decl
	to obtain the 'len' field from an explicit function result when
	in that function scope.

2017-11-23  Paul Thomas  <pault@gcc.gnu.org>

	Backported from trunk
	PR fortran/79072
	* gfortran.dg/class_result_5.f90: New test.
	* gfortran.dg/class_result_6.f90: New test.


Added:
    branches/gcc-7-branch/gcc/testsuite/gfortran.dg/class_result_5.f90
    branches/gcc-7-branch/gcc/testsuite/gfortran.dg/class_result_6.f90
Modified:
    branches/gcc-7-branch/gcc/fortran/ChangeLog
    branches/gcc-7-branch/gcc/fortran/trans-expr.c
    branches/gcc-7-branch/gcc/fortran/trans-stmt.c
    branches/gcc-7-branch/gcc/testsuite/ChangeLog

Shouldn't this PR be closed?

I just verified with 8.0 trunk (r257868) that all three of my examples continue to work as expected.

Let's close it then.

Thanks for the bug report!