[Bug fortran/49630] New: [OOP] ICE on obsolescent assumed length deferred type bound character function

[Bug fortran/49630] New: [OOP] ICE on obsolescent assumed length deferred type bound character function

[boschmann at tp1 dot physik.uni-siegen.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49630

           Summary: [OOP] ICE on obsolescent assumed length deferred type
                    bound character function
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: boschmann@tp1.physik.uni-siegen.de
                CC: janus@gcc.gnu.org


Here is one more weird piece of code:

module abc
  implicit none
  type,abstract::abc_abstract
   contains
     procedure(abc_interface),deferred::abc_function
  end type abc_abstract
  type,extends(abc_abstract)::abc_type
   contains
     procedure::abc_function
  end type abc_type
  abstract interface
     function abc_interface(this)
       import abc_abstract
       class(abc_abstract),intent(in)::this
       character(len=*)::abc_interface !obsolescent feature
     end function abc_interface
  end interface
contains
  function abc_function(this)
    class(abc_type),intent(in)::this
    character(len=5)::abc_function
    abc_function="hello"
  end function abc_function
  subroutine do_something(this)
    class(abc_abstract),intent(in)::this
    print *,this%abc_function()
  end subroutine do_something
end module abc

gcc 4.7 terminates with a segmentation fault. I get an ICE error message on my
full program, but it turned to a segfault in this reduced module.

Anyway this code doesn't look right, so I have tried some workarounds like
allocatable characters. But those ended up in different compiler errors.

So what is the state of allocatable character functions? Are they supposed to
work?

[Bug fortran/49630] [OOP] ICE on obsolescent deferred-length type bound character function

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49630

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu.org
            Summary|[OOP] ICE on obsolescent    |[OOP] ICE on obsolescent
                   |assumed length deferred     |deferred-length type bound
                   |type bound character        |character function
                   |function                    |

--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-07-04 15:53:29 UTC ---
Ragarding assumed-length functions: They should be supported, but no one has
tried something fancy (i.e. beyond F77 style of features) with them. They are
also really ugly.

Your test case fails for me with:

test.f90: In function ‘do_something’:
test.f90:26:0: internal compiler error: in build_int_cst_wide, at tree.c:1218

However, I think it is invalid to place an assumed-character-length function
into an INTERFACE. See PR 41604. (Cf. also PR 46588.)


> gcc 4.7 terminates with a segmentation fault. I get an ICE error message on my
> full program, but it turned to a segfault in this reduced module.

On my system with a slightly dated (20110629) gfortran, I get:

test.f90: In function ‘do_something’:
test.f90:26:0: internal compiler error: in build_int_cst_wide, at tree.c:1218


> So what is the state of allocatable character functions? Are they supposed to
> work?

You think mean those with deferred-length type parameter - the others should
already work just fine.

For deferred length: I think basic support is there, but there are still some
issues. Cf. also PR 49110 and PR 45170 comment 9.

[Bug fortran/49630] [OOP] ICE on obsolescent deferred-length type bound character function

[boschmann at tp1 dot physik.uni-siegen.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49630

--- Comment #2 from Hans-Werner Boschmann <boschmann at tp1 dot physik.uni-siegen.de> 2011-07-04 19:29:50 UTC ---
"C417: A function name shall not be declared with an asterisk type-param-value
unless it is of type CHAR- ACTER and is the name of the result of an external
function or the name of a dummy function."

So it is allowed to put an assumed character length into an interface, but not
in the way as I did in the code above. My example is invalid.

But how would I declare an abstract interface of a function with variable
length? I am allowed to use any scalar integer expression as length parameter
of a character function, but I cannot leave it empty in the interface. That's
why I use character(:),allocatable::res with the NAG fortran compiler. As far a
I know, this is the only valid way and that's why I am looking forward for
gfortran to implement it.

[Bug fortran/49630] [OOP] ICE on obsolescent deferred-length type bound character function

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49630

--- Comment #3 from janus at gcc dot gnu.org 2011-07-04 20:21:55 UTC ---
Here is a related deferred-length example:


module abc
  implicit none

  type::abc_type
   contains
     procedure::abc_function
  end type abc_type

contains

  function abc_function(this)
    class(abc_type),intent(in)::this
    character(:),allocatable::abc_function
    allocate(abc_function,source="hello")
  end function abc_function

  subroutine do_something(this)
    class(abc_type),intent(in)::this
    print *,this%abc_function()
  end subroutine do_something

end module abc


use abc
type(abc_type) :: a
call do_something(a)
end


This currently ICEs, but when changing the type-bound call in the "print" line
to a plain function call, i.e. "abc_function(this)", then it is accepted and
gives the expected output.

[Bug fortran/49630] [OOP] ICE on obsolescent deferred-length type bound character function

[zeccav at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49630

Vittorio Zecca <zeccav at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |zeccav at gmail dot com

--- Comment #5 from Vittorio Zecca <zeccav at gmail dot com> ---
Running the test case with gfortran 4.9.0 
I get a shift larger than HOST_BITS_PER_WIDE_INT (64 on x86-64)
in double-int.c:675 "m = ((unsigned HOST_WIDE_INT) 2 << (prec - 1)) - 1;"
because prec is 295.
Maybe this is connected to the original bug?