GCC Bugzilla has been upgraded from version 4.4.9 to 5.0rc3. If you see any problem, please report it to bug 64968.
Bug 45170 - [F2003] allocatable character lengths
Summary: [F2003] allocatable character lengths
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.6.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on: 47674 49954 50221 51976 56670 57910 47519 47523 49110 49430 51055 52843 53329 56138 57596
Blocks: 20585 51075 51394
  Show dependency treegraph
 
Reported: 2010-08-03 01:55 UTC by Norman S. Clerman
Modified: 2013-09-02 11:26 UTC (History)
11 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2011-01-28 20:43:16


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Norman S. Clerman 2010-08-03 01:55:38 UTC
gfortran tech support,

  When I attempt to compile the program listed below, the following error messages are printed:

norm@oxford:~/Elements/AllocChar$ more alloccharP.xyz 
alloccharP.f90:6.12:

  character(:), allocatable :: c_Char(:)
            1
Error: Syntax error in CHARACTER declaration at (1)
alloccharP.f90:7.12:

  character(:), allocatable :: io_message
            1
Error: Syntax error in CHARACTER declaration at (1)

  I searched the bug database but could not find this bug listed.

 I am attempting to declare an array of allocatable characters, which I believe is legal. The Intel 12.0 beta compiler and version 5.2 of the nag compiler both compile this routine. (The routine, as written, is not correct: the variable io_message needs to be allocated before it is used in the open statement.)

  Thank you for your attention.

Yours truly,

Norm

Norman S. Clerman

program AllocChar

  integer, parameter :: CHAR_ELEMENTS = 5, FILE_UNIT = 11
  integer :: io_stat
!  character(:), allocatable :: c_Char(CHAR_ELEMENTS)
  character(:), allocatable :: c_Char(:)
  character(:), allocatable :: io_message
  character (*), parameter :: FILE_NAME = "no_file.dat"

!  io_message = "no errors"
!  print *, io_message
!  c_Char = " "
!  c_Char(1: 2) = ["Hello     ", " everyone!"]
!  c_Char(1) = "Hello"
!  c_Char(2) = "everyone"
!  print *, c_Char (1: 2)

  open (unit = FILE_UNIT, file = FILE_NAME, iostat = io_stat, iomsg = io_message, status = "old")

  print *, io_message
  
end program AllocChar
Comment 1 kargl 2010-08-03 02:31:31 UTC
This statement:

character(:), allocatable :: io_message

uses a deferred type parameter (a F2003
feature), which is not supported by gfortran
at this time.
Comment 2 Tobias Burnus 2010-08-03 05:43:21 UTC
By the way, gfortran's Fortran 2003 implementation status can be found at
http://gcc.gnu.org/wiki/Fortran2003Status
Comment 3 Norman S. Clerman 2010-08-03 10:24:57 UTC
Subject: Re:  [F2003] allocatable character lengths

  Thank you very much for replying so promptly. I looked at the status page I didn't read it carefully enough.

Regards,

Norm Clerman

---- burnus at gcc dot gnu dot org <gcc-bugzilla@gcc.gnu.org> wrote: 

=============


------- Comment #2 from burnus at gcc dot gnu dot org  2010-08-03 05:43 -------
By the way, gfortran's Fortran 2003 implementation status can be found at
http://gcc.gnu.org/wiki/Fortran2003Status


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
OtherBugsDependingO|                            |20585
              nThis|                            |
            Summary|suspected bug in error      |[F2003] allocatable
                   |generated by allocatable    |character lengths
                   |character array             |


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

------- You are receiving this mail because: -------
You reported the bug, or are watching the reporter.

Comment 4 kargl 2010-08-15 18:46:24 UTC
A patch to do the parsing and some error checking has
been posted at

http://gcc.gnu.org/ml/fortran/2010-08/msg00181.html

It is not a complete implementation of the feature
and requires much additional work.
Comment 5 Tobias Burnus 2010-11-02 17:10:05 UTC
Author: burnus
Date: Tue Nov  2 17:09:58 2010
New Revision: 166205

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166205
Log:
2010-11-02  Steven G. Kargl  < kargl@gcc.gnu.org>
            Tobias Burnus  <burnus@net-b.de>

        PR fortran/45170
        * array.c (gfc_match_array_constructor): Reject deferred type
        parameter (DTP) in type-spec.
        * decl.c (char_len_param_value, match_char_length,
        gfc_match_char_spec, build_sym, variable_decl,
        enumerator_decl): Support DTP.
        * expr.c (check_inquiry): Fix check due to support for DTP.
        * gfortran.h (gfc_typespec): Add Boolean 'deferred'.
        * misc.c (gfc_clear_ts): Set it to false.
        * match.c (gfc_match_allocate): Support DTP.
        * resolve.c (resolve_allocate_expr): Not-implemented error for
        * DTP.
        (resolve_fl_variable): Add DTP constraint check.
        * trans-decl.c (gfc_trans_deferred_vars): Add not-implemented
        error for DTP.

2010-11-02  Steven G. Kargl  < kargl@gcc.gnu.org>
            Tobias Burnus  <burnus@net-b.de>

        PR fortran/45170
        * gfortran.dg/deferred_type_param_1.f90: New.
        * gfortran.dg/deferred_type_param_2.f90: New.
        * gfortran.dg/initialization_1.f90: Update dg-errors.
        * gfortran.dg/initialization_9.f90: Update dg-errors.


Added:
    trunk/gcc/testsuite/gfortran.dg/deferred_type_param_1.f90
    trunk/gcc/testsuite/gfortran.dg/deferred_type_param_2.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/array.c
    trunk/gcc/fortran/decl.c
    trunk/gcc/fortran/expr.c
    trunk/gcc/fortran/gfortran.h
    trunk/gcc/fortran/match.c
    trunk/gcc/fortran/misc.c
    trunk/gcc/fortran/resolve.c
    trunk/gcc/fortran/trans-decl.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gfortran.dg/allocate_with_typespec_3.f90
    trunk/gcc/testsuite/gfortran.dg/initialization_1.f90
    trunk/gcc/testsuite/gfortran.dg/initialization_9.f90
Comment 6 Tobias Burnus 2010-11-02 22:32:26 UTC
Parsing patch committed.

TODO: Actual implementation; will probably done as follow up to PR 35810.
Comment 7 Tobias Burnus 2011-01-27 21:04:27 UTC
Submitted patch for deferred-length character strings (only for scalars):
  http://gcc.gnu.org/ml/fortran/2011-01/msg00264.html
Also supports (re)allocate on assignment for scalars (PR 35810).
Comment 8 Paul Thomas 2011-01-28 13:53:25 UTC
Author: pault
Date: Fri Jan 28 13:53:19 2011
New Revision: 169356

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169356
Log:
2011-01-28  Paul Thomas  <pault@gcc.gnu.org>
	    Tobias Burnus  <burnus@gcc.gnu.org>

	PR fortran/45170
	PR fortran/35810
	PR fortran/47350
	* interface.c (compare_actual_formal): An allocatable or pointer
	deferred length actual is only allowed if the formal argument
	is also deferred length. Clean up whitespace.
	* trans-expr.c (gfc_conv_procedure_call): Pass string length for
	deferred character length formal arguments by reference. Do the
	same for function results.
	(gfc_trans_pointer_assignment): Do not do runtime check of lhs
	and rhs character lengths, if deferred length lhs.  In this case
	set the lhs character length to that of the rhs.
	(gfc_conv_string_parameter): Remove assert that string length is
	an integer type.
	(is_scalar_reallocatable_lhs): New function.
	(alloc_scalar_allocatable_for_assignment): New function.
	(gfc_trans_assignment_1): Call above new function. If the rhs is
	a deferred character length itself, makes ure that the function
	is called before reallocation, so that the length is available.
	(gfc_trans_asssignment): Remove error about assignment to
	deferred length character variables.
	* gfortran.texi : Update entry about (re)allocation on
	assignment.
	* trans-stmt.c (gfc_trans_allocate): Add code to handle deferred
	length character variables.
	* module.c (mio_typespec): Transfer deferred characteristic.
	* trans-types.c (gfc_get_function_type): New code to generate
	hidden typelist, so that those character lengths that are
	passed by reference get the right type.
	* resolve.c (resolve_contained_fntype): Supress error for
	deferred character length functions.
	(resolve_function, resolve_fl_procedure) The same.
	(check_symbols): Remove the error that support for
	entity with deferred type parameter is not yet implemented.
	(resolve_fl_derived): The same.
	match.c (alloc_opt_list): Allow MOLD for deferred length object.
	* trans-decl.c (gfc_get_symbol_decl): For deferred character
	length dummies, generate a local variable for string length.
	(create_function_arglist): Hidden length can be a pointer.
	(gfc_trans_deferred_vars): For deferred character length
	results and dummies, assign the string length to the local
	variable from the hidden argument on entry and the other way
	round on exit, as appropriate.

2011-01-28  Paul Thomas  <pault@gcc.gnu.org>
	    Tobias Burnus  <burnus@gcc.gnu.org>

	PR fortran/45170
	PR fortran/35810
	PR fortran/47350
	* gfortran.dg/realloc_on_assign_3.f03: New test.
	* gfortran.dg/realloc_on_assign_4.f03: New test.
	* gfortran.dg/realloc_on_assign_5.f90: New test.
	* gfortran.dg/allocatable_function_5.f90: New test.
	* gfortran.dg/allocate_deferred_char_scalar_1.f90: New test.
	* gfortran.dg/deferred_type_param_2.f90: Remove two "not yet
	implemented" dg-errors.


Added:
    trunk/gcc/testsuite/gfortran.dg/allocate_deferred_char_scalar_1.f03
    trunk/gcc/testsuite/gfortran.dg/realloc_on_assign_3.f03
    trunk/gcc/testsuite/gfortran.dg/realloc_on_assign_4.f03
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/gfortran.texi
    trunk/gcc/fortran/interface.c
    trunk/gcc/fortran/match.c
    trunk/gcc/fortran/module.c
    trunk/gcc/fortran/resolve.c
    trunk/gcc/fortran/trans-decl.c
    trunk/gcc/fortran/trans-expr.c
    trunk/gcc/fortran/trans-stmt.c
    trunk/gcc/fortran/trans-types.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gfortran.dg/deferred_type_param_2.f90
Comment 9 Tobias Burnus 2011-01-28 15:35:02 UTC
TODO:

- Function result variables which are character(len=:), pointer
  (according to http://gcc.gnu.org/ml/fortran/2011-01/msg00264.html item (v))

- Deferred-length string ARRAYS have still some issues

- Deferred-length string as derived-type COMPONENTS are unimplemented

- PR 47519 is an ICE
Comment 10 Thomas Koenig 2011-01-28 20:43:16 UTC
Adding dependencies, confirming.
Comment 11 Paul Thomas 2011-01-30 17:50:06 UTC
Author: pault
Date: Sun Jan 30 17:50:01 2011
New Revision: 169413

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169413
Log:
2011-01-30  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/47523
	* trans-expr.c (gfc_trans_assignment_1): If the rhs is an op
	expr and is assigned to a deferred character length scalar,
	make sure that the function is called before reallocation,
	so that the length is available. Include procedure pointer
	and procedure pointer component rhs as well.

2011-01-30  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/47523
	* trans-expr.c (gfc_trans_assignment_1): If the rhs is an op
	expr and is assigned to a deferred character length scalar,
	make sure that the function is called before reallocation,
	so that the length is available. Include procedure pointer
	and procedure pointer component rhs as well.

	PR fortran/45170
	PR fortran/35810
	PR fortran/47350
	* gfortran.dg/allocatable_function_5.f90: New test not added by
	mistake on 2011-01-28.



Added:
    trunk/gcc/testsuite/gfortran.dg/allocatable_function_5.f90
    trunk/gcc/testsuite/gfortran.dg/realloc_on_assign_5.f03
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-expr.c
    trunk/gcc/testsuite/ChangeLog
Comment 12 Diego Novillo 2011-02-02 17:59:37 UTC
Author: dnovillo
Date: Wed Feb  2 17:59:29 2011
New Revision: 169666

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169666
Log:
2011-01-28  Paul Thomas  <pault@gcc.gnu.org>
	    Tobias Burnus  <burnus@gcc.gnu.org>

	PR fortran/45170
	PR fortran/35810
	PR fortran/47350
	* interface.c (compare_actual_formal): An allocatable or pointer
	deferred length actual is only allowed if the formal argument
	is also deferred length. Clean up whitespace.
	* trans-expr.c (gfc_conv_procedure_call): Pass string length for
	deferred character length formal arguments by reference. Do the
	same for function results.
	(gfc_trans_pointer_assignment): Do not do runtime check of lhs
	and rhs character lengths, if deferred length lhs.  In this case
	set the lhs character length to that of the rhs.
	(gfc_conv_string_parameter): Remove assert that string length is
	an integer type.
	(is_scalar_reallocatable_lhs): New function.
	(alloc_scalar_allocatable_for_assignment): New function.
	(gfc_trans_assignment_1): Call above new function. If the rhs is
	a deferred character length itself, makes ure that the function
	is called before reallocation, so that the length is available.
	(gfc_trans_asssignment): Remove error about assignment to
	deferred length character variables.
	* gfortran.texi : Update entry about (re)allocation on
	assignment.
	* trans-stmt.c (gfc_trans_allocate): Add code to handle deferred
	length character variables.
	* module.c (mio_typespec): Transfer deferred characteristic.
	* trans-types.c (gfc_get_function_type): New code to generate
	hidden typelist, so that those character lengths that are
	passed by reference get the right type.
	* resolve.c (resolve_contained_fntype): Supress error for
	deferred character length functions.
	(resolve_function, resolve_fl_procedure) The same.
	(check_symbols): Remove the error that support for
	entity with deferred type parameter is not yet implemented.
	(resolve_fl_derived): The same.
	match.c (alloc_opt_list): Allow MOLD for deferred length object.
	* trans-decl.c (gfc_get_symbol_decl): For deferred character
	length dummies, generate a local variable for string length.
	(create_function_arglist): Hidden length can be a pointer.
	(gfc_trans_deferred_vars): For deferred character length
	results and dummies, assign the string length to the local
	variable from the hidden argument on entry and the other way
	round on exit, as appropriate.

2011-01-28  Paul Thomas  <pault@gcc.gnu.org>
	    Tobias Burnus  <burnus@gcc.gnu.org>

	PR fortran/45170
	PR fortran/35810
	PR fortran/47350
	* gfortran.dg/realloc_on_assign_3.f03: New test.
	* gfortran.dg/realloc_on_assign_4.f03: New test.
	* gfortran.dg/realloc_on_assign_5.f90: New test.
	* gfortran.dg/allocatable_function_5.f90: New test.
	* gfortran.dg/allocate_deferred_char_scalar_1.f90: New test.
	* gfortran.dg/deferred_type_param_2.f90: Remove two "not yet
	implemented" dg-errors.

Added:
    branches/google/integration/gcc/testsuite/gfortran.dg/allocate_deferred_char_scalar_1.f03
    branches/google/integration/gcc/testsuite/gfortran.dg/realloc_on_assign_3.f03
    branches/google/integration/gcc/testsuite/gfortran.dg/realloc_on_assign_4.f03
Modified:
    branches/google/integration/gcc/fortran/ChangeLog
    branches/google/integration/gcc/fortran/gfortran.texi
    branches/google/integration/gcc/fortran/interface.c
    branches/google/integration/gcc/fortran/match.c
    branches/google/integration/gcc/fortran/module.c
    branches/google/integration/gcc/fortran/resolve.c
    branches/google/integration/gcc/fortran/trans-decl.c
    branches/google/integration/gcc/fortran/trans-expr.c
    branches/google/integration/gcc/fortran/trans-stmt.c
    branches/google/integration/gcc/fortran/trans-types.c
    branches/google/integration/gcc/testsuite/ChangeLog
    branches/google/integration/gcc/testsuite/gfortran.dg/deferred_type_param_2.f90
Comment 13 Diego Novillo 2011-02-02 18:04:35 UTC
Author: dnovillo
Date: Wed Feb  2 18:04:21 2011
New Revision: 169697

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169697
Log:
2011-01-30  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/47523
	* trans-expr.c (gfc_trans_assignment_1): If the rhs is an op
	expr and is assigned to a deferred character length scalar,
	make sure that the function is called before reallocation,
	so that the length is available. Include procedure pointer
	and procedure pointer component rhs as well.

2011-01-30  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/47523
	* trans-expr.c (gfc_trans_assignment_1): If the rhs is an op
	expr and is assigned to a deferred character length scalar,
	make sure that the function is called before reallocation,
	so that the length is available. Include procedure pointer
	and procedure pointer component rhs as well.

	PR fortran/45170
	PR fortran/35810
	PR fortran/47350
	* gfortran.dg/allocatable_function_5.f90: New test not added by
	mistake on 2011-01-28.

Added:
    branches/google/integration/gcc/testsuite/gfortran.dg/allocatable_function_5.f90
    branches/google/integration/gcc/testsuite/gfortran.dg/realloc_on_assign_5.f03
Modified:
    branches/google/integration/gcc/fortran/ChangeLog
    branches/google/integration/gcc/fortran/trans-expr.c
    branches/google/integration/gcc/testsuite/ChangeLog
Comment 14 Hans-Werner Boschmann 2011-07-12 13:51:08 UTC
I've got one more item for the TODO list:

character(:),allocatable::string
integer::length
length=5
allocate(character(len=length)::string)

This is not yet accepted by gfortran. Is there any other way to allocate "string" without a primitive like string=repeat(" ",10)?
Comment 15 Steve Kargl 2011-07-12 14:19:24 UTC
On Tue, Jul 12, 2011 at 01:51:40PM +0000, boschmann at tp1 dot physik.uni-siegen.de wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170
> 
> Hans-Werner Boschmann <boschmann at tp1 dot physik.uni-siegen.de> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |boschmann at tp1 dot
>                    |                            |physik.uni-siegen.de
> 
> --- Comment #14 from Hans-Werner Boschmann <boschmann at tp1 dot physik.uni-siegen.de> 2011-07-12 13:51:08 UTC ---
> I've got one more item for the TODO list:
> 
> character(:),allocatable::string
> integer::length
> length=5
> allocate(character(len=length)::string)
> 
> This is not yet accepted by gfortran. Is there any other way to allocate
> "string" without a primitive like string=repeat(" ",10)?

laptop:kargl[212] gfc4x -o z g.f90
laptop:kargl[213] ./z
 yes!!
laptop:kargl[214] cat g.f90
character(:),allocatable::string
string='yes!!'
print *, string
end
Comment 16 Tobias Burnus 2011-07-12 14:44:11 UTC
(In reply to comment #14)
> allocate(character(len=length)::string)
> 
> This is not yet accepted by gfortran. Is there any other way to allocate
> "string" without a primitive like string=repeat(" ",10)?

  Error: Variable 'length' cannot appear in the expression at (1)

That comes from the specification expression check. The check is called via
  resolve_types -> resolve_charlen -> resolve_index_expr -> gfc_specification_expr

Thus, one needs to somehow distinguish length specifications in the ALLOCATE from those in a type-declaration statement; I think one needs to modify both resolve_index_expr (not calling gfc_specification_expr) and resolve_charlen (not setting specification_expr).
Comment 17 Hans-Werner Boschmann 2011-07-12 15:00:22 UTC
This sounds like there is still a lot of work to do in this character issue. Has anyone ever managed to allocate such strings dynamically? In 

(In reply to comment #15)
> character(:),allocatable::string
> string='yes!!'
> print *, string
> end

the length is constant so you could use character(5)::string. That's not what I mean, I would like to have something like this:

PROGRAM helloworld
  character(:),allocatable::string
  real::rnd
  call random_number(rnd)
  call hello(ceiling(11*rnd),string)
  print *,string
contains
  subroutine hello (n,string)
    character(:),allocatable,intent(out)::string
    integer,intent(in)::n
    character(10)::helloworld="hello world"
    string=helloworld(:n)
  end subroutine hello
end PROGRAM helloworld

I guess that's not yet possible with gfortran.
Comment 18 Tobias Burnus 2011-07-15 14:02:45 UTC
(In reply to comment #16)
>   Error: Variable 'length' cannot appear in the expression at (1)
> That comes from the specification expression check.

If one removes the check, it works, i.e. it is just a resolution (resolve.c) problem and not a code generation one.


(In reply to comment #17)
>   subroutine hello (n,string)
>     character(:),allocatable,intent(out)::string
>     integer,intent(in)::n
>     string=helloworld(:n)

That one seems to be a very subtle issue, depending on the modifications (e.g. allocate(character(len=)) instead of alloc on assignment), one might get the correct string length - or even the correct string. Looking at the (original) dump, the string length should be always correct, hence, I think we generate a slightly wrong tree. The next step would be to look at -fdump-tree-optimized and then work backwards.
Comment 19 Damian Rouson 2011-08-09 02:09:56 UTC
Comment 9 states that gfortran does not yet support "function result variables which are character(len=:), pointer".  Presumably this also implies a lack of support for replacing these with allocatable, deferred-length character variables.  I'm adding the case below because it produces an ICE with gfortran 4.6.1:

$ cat speaker.F90
module speaker_class
  type speaker
  contains
    procedure :: speak
  end type
contains
  function speak(this)
    class(speaker) ,intent(in) :: this
    character(:) ,allocatable :: speak
  end function
  subroutine say_something(somebody)
    class(speaker) :: somebody
    print *,somebody%speak()
  end subroutine
end module

$ gfortran -c speaker.F90
speaker.F90: In function 'say_something':
speaker.F90:13:0: internal compiler error: in fold_convert_loc, at fold-const.c:1906
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

$ gfortran --version
GNU Fortran (GCC) 4.6.1 20110325 (prerelease)
Copyright (C) 2011 Free Software Foundation, Inc.

GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING
Comment 20 kargl 2011-08-09 03:48:11 UTC
(In reply to comment #19)
> Comment 9 states that gfortran does not yet support "function result variables
> which are character(len=:), pointer".  Presumably this also implies a lack of
> support for replacing these with allocatable, deferred-length character
> variables.  I'm adding the case below because it produces an ICE with gfortran
> 4.6.1:
> 
> $ cat speaker.F90
> module speaker_class
>   type speaker
>   contains
>     procedure :: speak
>   end type
> contains
>   function speak(this)
>     class(speaker) ,intent(in) :: this
>     character(:) ,allocatable :: speak
>   end function
>   subroutine say_something(somebody)
>     class(speaker) :: somebody
>     print *,somebody%speak()
>   end subroutine
> end module
> 
> $ gfortran -c speaker.F90
> speaker.F90: In function 'say_something':
> speaker.F90:13:0: internal compiler error: in fold_convert_loc, at
> fold-const.c:1906
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <http://gcc.gnu.org/bugs.html> for instructions.

It works fine if you remove all the extraneous garbage in 
your example.

laptop:kargl[217] cat foo.f90
module speaker_class
contains
  function speak()
    character(:) , allocatable :: speak
    speak = 'foo'
  end function
end module

program foo
  use speaker_class
  print *, speak()
end program foo
laptop:kargl[218] gfc4x -o z foo.f90 && ./z
 foo
Comment 21 Damian Rouson 2011-08-09 04:26:45 UTC
Thanks but even the version with the "extraneous garbage" was reduced relative to what I really want to do (which includes making the speaker type abstract and the speak type-bound procedure deferred with a specified abstract interface) so having the reduced case doesn't help much. 

Regardless, hopefully you'll agree that an ICE is a compiler bug.  I guess the question is whether it is another example of Bug 45170 or should be submitted as a separate bug.
Comment 22 Steve Kargl 2011-08-09 05:09:13 UTC
On Tue, Aug 09, 2011 at 04:26:49AM +0000, damian at rouson dot net wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170
> 
> --- Comment #21 from Damian Rouson <damian at rouson dot net> 2011-08-09 04:26:45 UTC ---
> Thanks but even the version with the "extraneous garbage" was reduced relative
> to what I really want to do (which includes making the speaker type abstract
> and the speak type-bound procedure deferred with a specified abstract
> interface) so having the reduced case doesn't help much. 
> 
> Regardless, hopefully you'll agree that an ICE is a compiler bug.  I guess the
> question is whether it is another example of Bug 45170 or should be submitted
> as a separate bug.

Yes, it is bug.  It is not as drastic as you stated.
Clearly, I demonstrated that a function can have a deferred
type parameter as a result.  The problem appears to be an
OOP issue.
Comment 23 Hans-Werner Boschmann 2011-08-26 10:05:32 UTC
Is there any chance that gfortran 4.7.0 will support allocatable character lengths? Using fortran for text processing has been painful since time immemorial and this little feature is a huge leap indeed.

Unlike iso_varying_string you can combine allocatable characters to all other built-in features of fortran like print *,string. Additionally, as soon as it is allocated, you can assign it to a non-allocatable dummy characters so no one but the supplier has to care about whether it is dynamic or not. That's why it is much more powerful than iso_varying_string.
Comment 24 Steve Kargl 2011-08-26 17:23:11 UTC
On Fri, Aug 26, 2011 at 10:05:32AM +0000, boschmann at tp1 dot physik.uni-siegen.de wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170
> 
> --- Comment #23 from Hans-Werner Boschmann <boschmann at tp1 dot physik.uni-siegen.de> 2011-08-26 10:05:32 UTC ---
> Is there any chance that gfortran 4.7.0 will support allocatable character
> lengths?

As you know, gfortran already has support for a deferred
type parameter.  Yes, there are some bugs, but no one
has had time to track down the few remaining issues.
Looking at your code in comment #17, one can easily find
a trivial change to make it work.


PROGRAM helloworld
  character(:),allocatable::string
  real::rnd
  do i = 1, 10
     call random_number(rnd)
     call hello(ceiling(11*rnd),string)
     print '(A,1X,I0)', '>' // string // '<', len(string)
  end do
contains
  subroutine hello (n,string)
    character(:),allocatable,intent(out)::string
    integer,intent(in)::n
    character(10)::helloworld="hello world"
!    string=helloworld(:n)                      ! Does not work.
!    string=(helloworld(:n))                    ! Works.
!    allocate(string, source=helloworld(:n))    ! Does not work.
     allocate(string, source=(helloworld(:n)))  ! Works.
  end subroutine hello
end PROGRAM helloworld

troutmask:sgk[217] gfc4x -o z foo.f90 && ./z
>hello worl< 11
>hello w< 7
>hello worl< 11
>hello wor< 9
>hello< 5
>hello < 6
>h< 1
>h< 1
>hell< 4
>hell< 4

Your code in comment #14 is (I believe) invalid, and gfortran
is issuing the correct error message.
Comment 25 Hans-Werner Boschmann 2011-08-26 19:44:10 UTC
(In reply to comment #24)
 
> Looking at your code in comment #17, one can easily find
> a trivial change to make it work.

Thank you, I was not aware of this. I was always wondering why you said that it is partly working, because I could not at all allocate characters. But knowing this, I should be able to fix my code.

> Yes, there are some bugs, but no one
> has had time to track down the few remaining issues.

Sure, please don't feel pushed. It is in fact a miracle that you keep up with companies like intel or portland without comparable funding. Great job!
Comment 26 Tobias Burnus 2011-08-29 06:47:41 UTC
(In reply to comment #24)
> Your code in comment #14 is (I believe) invalid, and gfortran
> is issuing the correct error message.

I get:
  Error: Variable 'length' cannot appear in the expression at (1)

However, I believe that 
  allocate(character(len=length)::string)
is valid.

One has (F2008):
  R626 allocate-stmt is ALLOCATE ( [ type-spec :: ] allocation-list
                                   [, alloc-opt-list ] )
with
  R402 type-spec  is  intrinsic-type-spec  or  derived-type-spec
with 
  R404 intrinsic-type-spec  is  [...]
                            or  CHARACTER [ char-selector ]
with
  R420 char-selector  is  length-selector [or ...]
with
  R421 length-selector is ( [ LEN = ] type-param-value )  [or ...]

Thus, I do not see any syntax problems; I also couldn't find any constraint or other reason which renders the code in comment #14 invalid.
Comment 27 Steve Kargl 2011-08-29 16:22:16 UTC
On Mon, Aug 29, 2011 at 06:47:41AM +0000, burnus at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170
> 
> --- Comment #26 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-08-29 06:47:41 UTC ---
> (In reply to comment #24)
> > Your code in comment #14 is (I believe) invalid, and gfortran
> > is issuing the correct error message.
> 
> I get:
>   Error: Variable 'length' cannot appear in the expression at (1)
> 
> However, I believe that 
>   allocate(character(len=length)::string)
> is valid.
> 
> One has (F2008):
>   R626 allocate-stmt is ALLOCATE ( [ type-spec :: ] allocation-list
>                                    [, alloc-opt-list ] )
> with
>   R402 type-spec  is  intrinsic-type-spec  or  derived-type-spec
> with 
>   R404 intrinsic-type-spec  is  [...]
>                             or  CHARACTER [ char-selector ]
> with
>   R420 char-selector  is  length-selector [or ...]
> with
>   R421 length-selector is ( [ LEN = ] type-param-value )  [or ...]
> 

From F2003:

C402 (R402) The type-param-value for a kind type parameter shall be
an initialization expression.

7.1.7

An initialization expression is an expression with limitations that
make it suitable for use as a kind type parameter, initializer, or
named constant.  It is an expression in which each operation is
intrinsic, and each primary is

      (1)   A constant or subobject of a constant,


character(:),allocatable::string
integer::length
length=5
allocate(character(len=length)::string)

length is not a constant.
Comment 28 Tobias Burnus 2011-08-29 16:34:34 UTC
(In reply to comment #27)
> >   R421 length-selector is ( [ LEN = ] type-param-value )  [or ...]
> 
> From F2003:
> 
> C402 (R402) The type-param-value for a kind type parameter shall be
> an initialization expression.
[...]
> allocate(character(len=length)::string)
> 
> length is not a constant.

Nor is it a "type-param-value for a *kind* type parameter" (emphasis by me). It is a "length type parameter":

"1.3.147.12.4  length type parameter  type parameter whose value is permitted to be assumed, deferred, or given by a specification expression"

In your case, it is deferred. Note that type-param-value is simply defined as:
  R401 type-param-value  is  scalar-int-expr  or  *  or  :
and
  "The values of the deferred type parameters of an object are determined by successful execution of an ALLOCATE statement (6.7.1), execution of an intrinsic assignment statement (7.2.1.3), execution of a pointer assignment statement (7.2.2), or by argument association (12.5.2)."
Comment 29 kargl 2011-08-30 15:34:06 UTC
Author: kargl
Date: Tue Aug 30 15:34:01 2011
New Revision: 178329

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178329
Log:
2011-08-30  Steven G. Kargl  <kargl@gcc.gnu.org>

	PR fortran/45170
	* trans-stmt.c (gfc_trans_allocate): Evaluate the substring.

2011-08-30  Steven G. Kargl  <kargl@gcc.gnu.org>

	PR fortran/45170
	* gfortran.dg/allocate_with_source_2.f90: New test

Added:
    trunk/gcc/testsuite/gfortran.dg/allocate_with_source_2.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-stmt.c
    trunk/gcc/testsuite/ChangeLog
Comment 30 Damian Rouson 2011-08-30 18:46:42 UTC
Just out curiosity, what's the reason for the "real::rnd" line in the
helloworld testcase?  I don't see "rnd" used anywhere.

Damian

On Tue, Aug 30, 2011 at 8:34 AM, kargl at gcc dot gnu.org <
gcc-bugzilla@gcc.gnu.org> wrote:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170
>
> --- Comment #29 from kargl at gcc dot gnu.org 2011-08-30 15:34:06 UTC ---
> Author: kargl
> Date: Tue Aug 30 15:34:01 2011
> New Revision: 178329
>
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=178329
> Log:
> 2011-08-30  Steven G. Kargl  <kargl@gcc.gnu.org>
>
>    PR fortran/45170
>    * trans-stmt.c (gfc_trans_allocate): Evaluate the substring.
>
> 2011-08-30  Steven G. Kargl  <kargl@gcc.gnu.org>
>
>    PR fortran/45170
>    * gfortran.dg/allocate_with_source_2.f90: New test
>
> Added:
>    trunk/gcc/testsuite/gfortran.dg/allocate_with_source_2.f90
> Modified:
>    trunk/gcc/fortran/ChangeLog
>    trunk/gcc/fortran/trans-stmt.c
>    trunk/gcc/testsuite/ChangeLog
>
> --
> Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.
>
Comment 31 Steve Kargl 2011-08-30 19:31:25 UTC
On Tue, Aug 30, 2011 at 06:46:42PM +0000, damian at rouson dot net wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170
> 
> --- Comment #30 from Damian Rouson <damian at rouson dot net> 2011-08-30 18:46:42 UTC ---
> Just out curiosity, what's the reason for the "real::rnd" line in the
> helloworld testcase?  I don't see "rnd" used anywhere.
> 
> Damian
> 

When I changed the testcase from the PR into something
suitable for the testsuite, I missed removing the
declaration.
Comment 32 Tobias Burnus 2012-05-13 10:52:37 UTC
Author: burnus
Date: Sun May 13 10:52:32 2012
New Revision: 187436

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187436
Log:
2012-05-13  Alessandro Fanfarillo  <fanfarillo.gcc@gmail.com>
            Tobias Burnus  <burnus@net-b.de>

        PR fortran/52158
        PR fortran/45170
        PR fortran/49430
        * resolve.c (resolve_fl_derived0): Deferred character length 
        procedure components are supported.
        * trans-expr.c (gfc_conv_procedure_call): Handle TBP with 
        deferred-length results.
        (gfc_string_to_single_character): Add a new check to prevent
        NULL read.
        (gfc_conv_procedure_call): Remove unuseful checks on 
        symbol's attributes. Add new checks to prevent NULL read on
        string length. 

2012-05-13  Alessandro Fanfarillo  <fanfarillo.gcc@gmail.com>

        PR fortran/45170
        * gfortran.dg/deferred_type_param_3.f90: New.
        * gfortran.dg/deferred_type_proc_pointer_1.f90: New.
        * gfortran.dg/deferred_type_proc_pointer_2.f90: New.


Added:
    trunk/gcc/testsuite/gfortran.dg/deferred_type_param_3.f90
    trunk/gcc/testsuite/gfortran.dg/deferred_type_proc_pointer_1.f90
    trunk/gcc/testsuite/gfortran.dg/deferred_type_proc_pointer_2.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/resolve.c
    trunk/gcc/fortran/trans-expr.c
    trunk/gcc/testsuite/ChangeLog
Comment 33 Tobias Burnus 2012-05-13 12:45:46 UTC
STATUS: Many issues have been fixed, but several still exist.

- See list of bugs which depend on/block this PR.

Regarding the bugs reported/mentioned directly in this PR:

- Comment 0 seems to be fixed except for the array assignment, cf. PR 50221.
- Comment 14 is the same as PR 51055
  (A simple REPEAT, which is suggested as alternative in comment 14 does not
   yet work, cf. submitted patch and PR 49110 and PR 51055)
- Comment 24: The first example (first commented "Does not work." line) still
  fails. Warning: It seems to use an an endless loop in which it keeps
  allocating memory!

As comment 9 mentioned:
- Deferred-length string ARRAYS have still some issues; for instance PR 50221.
- Deferred-length strings as derived-type COMPONENTS are unimplemented
  That's PR 51976.
Comment 34 Tobias Burnus 2012-05-15 12:54:36 UTC
(In reply to comment #24)
>      call hello(ceiling(11*rnd),string)

That should be floor or "10" - otherwise, it can give "11" which is too large. (Or and better: Change the "10" to "11" below then "hello worl(d)" fits into the string.)


>     integer,intent(in)::n
>     character(10)::helloworld="hello world"
>     string=helloworld(:n)                      ! Does not work.

Interestingly, it works if one does not use "n" as argument but sets it in the procedure. One then gets code like:
  *string =  ... __builtin_malloc ( ... MAX_EXPR <n, 0> )

However, if "n" is passed as dummy argument, one has:
  integer(kind=4) D.1865;
  *string = ... __builtin_malloc ( ... MAX_EXPR <D.1865, 0> )
  D.1865 = *nnnn;

Or in other words: The order is wrong.
Comment 35 Tobias Burnus 2012-05-23 20:35:42 UTC
Author: burnus
Date: Wed May 23 20:35:30 2012
New Revision: 187811

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=187811
Log:
2012-05-23  Tobias Burnus  <burnus@net-b.de>

        PR fortran/51055
        PR fortran/45170
        * match.c (gfc_match_allocate): Set length_from_typespec
        for characters.
        * resolve.c (resolve_charlen): If set, don't check whether
        the len is a specification expression.

2012-05-23  Tobias Burnus  <burnus@net-b.de>

        PR fortran/51055
        PR fortran/45170
        * gfortran.dg/allocate_with_typespec_6.f90: New.


Added:
    trunk/gcc/testsuite/gfortran.dg/allocate_with_typespec_6.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/match.c
    trunk/gcc/fortran/resolve.c
    trunk/gcc/testsuite/ChangeLog
Comment 36 Tobias Burnus 2012-05-23 20:45:29 UTC
(In reply to comment #35)
> New Revision: 187811

That patch fixed comment 14.

REMAINING issues:

- comment 24 first "Does not work.", see also comment 34
- PRs which block this PR, some of them are also mentioned in
  this PR (cf. comment 33).
Comment 37 Tobias Burnus 2012-05-24 13:08:33 UTC
(In reply to comment #36)
> REMAINING issues:
> - comment 24 first "Does not work.", see also comment 34

One has in gfc_trans_assignment_1:

   string_length = gfc_evaluate_now (rse.string_length, &rse.pre);
   ...
   if (...)
     gfc_add_block_to_block (&block, &rse.pre);

where the (...) evaluates to false. (The call in gfc_trans_scalar_assign then works on rse->string_length, which seems seems to handle the gfc_add_block_to_block for rse.pre.)

The following works, but I am not sure about the condition; I have the feeling that it could be handled unconditionally.

--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -6893,3 +6897,2 @@ gfc_trans_assignment_1 (gfc_expr * expr1, gfc_expr * expr2, bool init_flag,
   bool scalar_to_array;
-  bool def_clen_func;
   tree string_length;
@@ -7012,9 +7015,4 @@ gfc_trans_assignment_1 (gfc_expr * expr1, gfc_expr * expr2, bool init_flag,
      parameter available to the caller; gfortran saves it in the .mod files. */
-  def_clen_func = (expr2->expr_type == EXPR_FUNCTION
-                  || expr2->expr_type == EXPR_COMPCALL
-                  || expr2->expr_type == EXPR_PPC);
-  if (gfc_option.flag_realloc_lhs
-       && expr2->ts.type == BT_CHARACTER
-       && (def_clen_func || expr2->expr_type == EXPR_OP)
-       && expr1->ts.deferred)
+  if (gfc_option.flag_realloc_lhs && expr2->ts.type == BT_CHARACTER
+      && expr1->ts.deferred)
     gfc_add_block_to_block (&block, &rse.pre);
Comment 38 Tobias Burnus 2012-06-16 18:13:42 UTC
Author: burnus
Date: Sat Jun 16 18:13:38 2012
New Revision: 188692

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188692
Log:
2012-06-16  Tobias Burnus  <burnus@net-b.de>

        PR fortran/53642
        PR fortran/45170
        * frontend-passes.c (optimize_assignment): Don't remove RHS's
        trim when assigning to a deferred-length string.
        * trans-expr.c (gfc_trans_assignment_1): Ensure that the RHS string
        length is evaluated before the deferred-length LHS is reallocated.

2012-06-16  Tobias Burnus  <burnus@net-b.de>

        PR fortran/53642
        PR fortran/45170
        * gfortran.dg/deferred_type_param_8.f90: New.


Added:
    trunk/gcc/testsuite/gfortran.dg/deferred_type_param_8.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/frontend-passes.c
    trunk/gcc/fortran/trans-expr.c
    trunk/gcc/testsuite/ChangeLog
Comment 39 Tobias Burnus 2012-06-16 18:28:31 UTC
The issue of comment 24 is now fixed (comment 38). Thus, only the following issues remain, which are all covered in other bugs (see dependency list):

* PR 50221: Allocatable string length fails with array assignment
  Cf. also comment 0 and comment 9

* PR 47674: gfortran.dg/realloc_on_assign_5.f03:
  Segfault at run time for deferred (allocatable) string length
  Related to missing dependency handling for substrings like: "a = a(1:4)"

* PR 49954: ICE assigning concat expression to an array deferred-length string
  (realloc on assignment)
  Related to the problem that expr->ts.u.cl->backend_decl points to the wrong
  result.

* PR 51976: [F2003] Support deferred-length character components of derived
  types (allocatable string length)
  Similar to the previous issue: expr->ts.u.cl->backend_decl is wrong, one needs
  to convert it to dt_var._hidden_length. (Well, the "_hidden_length" is
  also not yet implemented in the trunk.)
  (Cf. also comment 9)
Comment 40 I M 2013-02-05 16:33:13 UTC
With version 4.7.2 this bug still exists. Is there any timeline to fix it?
Comment 41 I M 2013-02-05 16:36:41 UTC
With version 4.7.2 this bug still exists. Is there any timeline to fix it? 

The following code 

module thing
    implicit none
    character(len=:), allocatable :: array_of_chars(:)
    contains

      subroutine allocatestuff()
        implicit none
        integer :: length_names = 15
        integer :: number_arrays  = 5

        allocate(character(15) :: array_of_chars(number_arrays))
        !allocate(character(length_names) :: array_of_chars(number_arrays))

      end subroutine allocatestuff
 
end module thing

program test1
implicit none


      call allocatestuff()

end program test1

Both allocates triggers the bug. If the same code is in the main program and not in a module the first allocate works, but the second doesn't.
Comment 42 janus 2013-02-05 20:22:25 UTC
(In reply to comment #41)
> With version 4.7.2 this bug still exists. Is there any timeline to fix it? 
> 
> [...]
> 
> Both allocates triggers the bug. If the same code is in the main program and
> not in a module the first allocate works, but the second doesn't.

While your test case ICEs with 4.6 and 4.7 (internal compiler error: in lhd_set_decl_assembler_name, at langhooks.c:158), it works with the current trunk version (if you add "use thing"), so it should also work with the upcoming release 4.8.0.

Note that there are still some known bugs, though (cf. comment 39).
Comment 43 Dominique d'Humieres 2013-06-25 18:02:34 UTC
Per comment #39, it seems that this PR could be closed as FIXED.
Comment 44 Dominique d'Humieres 2013-09-02 11:26:12 UTC
> Per comment #39, it seems that this PR could be closed as FIXED.

Closing as fixed. If there are issues not covered by comment #39, please open a new report.