Bug 49630 - [OOP] ICE on obsolescent deferred-length type bound character function
Summary: [OOP] ICE on obsolescent deferred-length type bound character function
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.7.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-07-04 15:31 UTC by Hans-Werner Boschmann
Modified: 2014-04-29 16:16 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2013-06-12 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Hans-Werner Boschmann 2011-07-04 15:31:52 UTC
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?
Comment 1 Tobias Burnus 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.
Comment 2 Hans-Werner Boschmann 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.
Comment 3 janus 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.
Comment 4 Dominique d'Humieres 2013-06-12 10:01:31 UTC
For the code in comment #0, I get the following ICE:

In function 'do_something':
Segmentation fault
     print *,this%abc_function()
 ^

Internal compiler error: Error reporting routines re-entered.
gfcc: internal compiler error: Abort trap (program f951)

or

pr49630.f90: In function 'do_something':
pr49630.f90:26:0: internal compiler error: in build_int_cst_wide, at tree.c:1213
     print *,this%abc_function()
 ^

pr49630.f90:26:0: internal compiler error: Abort trap
gfca: internal compiler error: Abort trap (program f951)

for versions configured with --enable-checking=release.

AFAICT the code in comment #1 compiles with 4.8 and trunk (it is not supported in 4.7).
Comment 5 Vittorio Zecca 2014-04-29 16:16:18 UTC
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?