This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug fortran/49630] [OOP] ICE on obsolescent deferred-length type bound character function
- From: "burnus at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Mon, 4 Jul 2011 15:55:11 +0000
- Subject: [Bug fortran/49630] [OOP] ICE on obsolescent deferred-length type bound character function
- Auto-submitted: auto-generated
- References: <bug-49630-4@http.gcc.gnu.org/bugzilla/>
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.