[Bug fortran/45170] [F2003] allocatable character lengths
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 janus at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug fortran/45170] [F2003] allocatable character lengths
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 Bug 45170 depends on bug 57910, which changed state. Bug 57910 Summary: ICE (segfault) with deferred-length strings https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57910 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/45170] [F2003] allocatable character lengths
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 Bug 45170 depends on bug 50221, which changed state. Bug 50221 Summary: Allocatable string length fails with array assignment https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50221 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/45170] [F2003] allocatable character lengths
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 Bug 45170 depends on bug 49954, which changed state. Bug 49954 Summary: ICE assigning concat expression to an array deferred-length string (realloc on assignment) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49954 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/45170] [F2003] allocatable character lengths
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 Bug 45170 depends on bug 51976, which changed state. Bug 51976 Summary: [F2003] Support deferred-length character components of derived types (allocatable string length) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51976 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/45170] [F2003] allocatable character lengths
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 Bug 45170 depends on bug 47674, which changed state. Bug 47674 Summary: gfortran.dg/realloc_on_assign_5.f03: Segfault at run time for deferred (allocatable) string length https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47674 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/45170] [F2003] allocatable character lengths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #44 from Dominique d'Humieres dominiq at lps dot ens.fr --- 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.
[Bug fortran/45170] [F2003] allocatable character lengths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|NEW |WAITING --- Comment #43 from Dominique d'Humieres dominiq at lps dot ens.fr --- Per comment #39, it seems that this PR could be closed as FIXED.
[Bug fortran/45170] [F2003] allocatable character lengths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 Bug 45170 depends on bug 57596, which changed state. Bug 57596 Summary: Wrong code for allocatable deferred-length strings http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57596 What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED
[Bug fortran/45170] [F2003] allocatable character lengths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 Bug 45170 depends on bug 57596, which changed state. Bug 57596 Summary: Wrong code for allocatable deferred-length strings http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57596 What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |---
[Bug fortran/45170] [F2003] allocatable character lengths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 I M infinity.probability at gmail dot com changed: What|Removed |Added CC||infinity.probability at ||gmail dot com --- Comment #40 from I M infinity.probability at gmail dot com 2013-02-05 16:33:13 UTC --- With version 4.7.2 this bug still exists. Is there any timeline to fix it?
[Bug fortran/45170] [F2003] allocatable character lengths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 --- Comment #41 from I M infinity.probability at gmail dot com 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.
[Bug fortran/45170] [F2003] allocatable character lengths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 --- Comment #42 from janus at gcc dot gnu.org 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).
[Bug fortran/45170] [F2003] allocatable character lengths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 --- Comment #38 from Tobias Burnus burnus at gcc dot gnu.org 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=gccview=revrev=188692 Log: 2012-06-16 Tobias Burnus bur...@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 bur...@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
[Bug fortran/45170] [F2003] allocatable character lengths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 --- Comment #39 from Tobias Burnus burnus at gcc dot gnu.org 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)
[Bug fortran/45170] [F2003] allocatable character lengths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 --- Comment #37 from Tobias Burnus burnus at gcc dot gnu.org 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);
[Bug fortran/45170] [F2003] allocatable character lengths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 --- Comment #35 from Tobias Burnus burnus at gcc dot gnu.org 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=gccview=revrev=187811 Log: 2012-05-23 Tobias Burnus bur...@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 bur...@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
[Bug fortran/45170] [F2003] allocatable character lengths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 --- Comment #36 from Tobias Burnus burnus at gcc dot gnu.org 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).
[Bug fortran/45170] [F2003] allocatable character lengths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 --- Comment #34 from Tobias Burnus burnus at gcc dot gnu.org 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 = *; Or in other words: The order is wrong.
[Bug fortran/45170] [F2003] allocatable character lengths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 --- Comment #32 from Tobias Burnus burnus at gcc dot gnu.org 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=gccview=revrev=187436 Log: 2012-05-13 Alessandro Fanfarillo fanfarillo@gmail.com Tobias Burnus bur...@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@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
[Bug fortran/45170] [F2003] allocatable character lengths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 --- Comment #33 from Tobias Burnus burnus at gcc dot gnu.org 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.
[Bug fortran/45170] [F2003] allocatable character lengths
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=gccview=revrev=178329 Log: 2011-08-30 Steven G. Kargl ka...@gcc.gnu.org PR fortran/45170 * trans-stmt.c (gfc_trans_allocate): Evaluate the substring. 2011-08-30 Steven G. Kargl ka...@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
[Bug fortran/45170] [F2003] allocatable character lengths
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 On Tue, Aug 30, 2011 at 8:34 AM, kargl at gcc dot gnu.org gcc-bugzi...@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=gccview=revrev=178329 Log: 2011-08-30 Steven G. Kargl ka...@gcc.gnu.org PR fortran/45170 * trans-stmt.c (gfc_trans_allocate): Evaluate the substring. 2011-08-30 Steven G. Kargl ka...@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.
[Bug fortran/45170] [F2003] allocatable character lengths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 --- Comment #31 from Steve Kargl sgk at troutmask dot apl.washington.edu 2011-08-30 19:31:25 UTC --- On Tue, Aug 30, 2011 at 06:46:42PM +, 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.
[Bug fortran/45170] [F2003] allocatable character lengths
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 ...] 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.
[Bug fortran/45170] [F2003] allocatable character lengths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 --- Comment #27 from Steve Kargl sgk at troutmask dot apl.washington.edu 2011-08-29 16:22:16 UTC --- On Mon, Aug 29, 2011 at 06:47:41AM +, 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.
[Bug fortran/45170] [F2003] allocatable character lengths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 --- Comment #28 from Tobias Burnus burnus at gcc dot gnu.org 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).
[Bug fortran/45170] [F2003] allocatable character lengths
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? 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.
[Bug fortran/45170] [F2003] allocatable character lengths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 --- Comment #24 from Steve Kargl sgk at troutmask dot apl.washington.edu 2011-08-26 17:23:11 UTC --- On Fri, Aug 26, 2011 at 10:05:32AM +, 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.
[Bug fortran/45170] [F2003] allocatable character lengths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 --- Comment #25 from Hans-Werner Boschmann boschmann at tp1 dot physik.uni-siegen.de 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!
[Bug fortran/45170] [F2003] allocatable character lengths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 Damian Rouson damian at rouson dot net changed: What|Removed |Added CC||damian at rouson dot net --- Comment #19 from Damian Rouson damian at rouson dot net 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
[Bug fortran/45170] [F2003] allocatable character lengths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 --- Comment #20 from kargl at gcc dot gnu.org 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
[Bug fortran/45170] [F2003] allocatable character lengths
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.
[Bug fortran/45170] [F2003] allocatable character lengths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 --- Comment #22 from Steve Kargl sgk at troutmask dot apl.washington.edu 2011-08-09 05:09:13 UTC --- On Tue, Aug 09, 2011 at 04:26:49AM +, 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.
[Bug fortran/45170] [F2003] allocatable character lengths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 --- Comment #18 from Tobias Burnus burnus at gcc dot gnu.org 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.
[Bug fortran/45170] [F2003] allocatable character lengths
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)?
[Bug fortran/45170] [F2003] allocatable character lengths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 --- Comment #15 from Steve Kargl sgk at troutmask dot apl.washington.edu 2011-07-12 14:19:24 UTC --- On Tue, Jul 12, 2011 at 01:51:40PM +, 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
[Bug fortran/45170] [F2003] allocatable character lengths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 --- Comment #16 from Tobias Burnus burnus at gcc dot gnu.org 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).
[Bug fortran/45170] [F2003] allocatable character lengths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 --- Comment #17 from Hans-Werner Boschmann boschmann at tp1 dot physik.uni-siegen.de 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.
[Bug fortran/45170] [F2003] allocatable character lengths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 --- Comment #12 from Diego Novillo dnovillo at gcc dot gnu.org 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=gccview=revrev=169666 Log: 2011-01-28 Paul Thomas pa...@gcc.gnu.org Tobias Burnus bur...@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 pa...@gcc.gnu.org Tobias Burnus bur...@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
[Bug fortran/45170] [F2003] allocatable character lengths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 --- Comment #13 from Diego Novillo dnovillo at gcc dot gnu.org 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=gccview=revrev=169697 Log: 2011-01-30 Paul Thomas pa...@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 pa...@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
[Bug fortran/45170] [F2003] allocatable character lengths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 --- Comment #11 from Paul Thomas pault at gcc dot gnu.org 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=gccview=revrev=169413 Log: 2011-01-30 Paul Thomas pa...@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 pa...@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
[Bug fortran/45170] [F2003] allocatable character lengths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 --- Comment #8 from Paul Thomas pault at gcc dot gnu.org 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=gccview=revrev=169356 Log: 2011-01-28 Paul Thomas pa...@gcc.gnu.org Tobias Burnus bur...@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 pa...@gcc.gnu.org Tobias Burnus bur...@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
[Bug fortran/45170] [F2003] allocatable character lengths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 --- Comment #9 from Tobias Burnus burnus at gcc dot gnu.org 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
[Bug fortran/45170] [F2003] allocatable character lengths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.01.28 20:43:16 CC||tkoenig at gcc dot gnu.org Depends on||47519, 47523 Ever Confirmed|0 |1 --- Comment #10 from Thomas Koenig tkoenig at gcc dot gnu.org 2011-01-28 20:43:16 UTC --- Adding dependencies, confirming.
[Bug fortran/45170] [F2003] allocatable character lengths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 --- Comment #7 from Tobias Burnus burnus at gcc dot gnu.org 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).
[Bug fortran/45170] [F2003] allocatable character lengths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 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=gccview=revrev=166205 Log: 2010-11-02 Steven G. Kargl ka...@gcc.gnu.org Tobias Burnus bur...@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 ka...@gcc.gnu.org Tobias Burnus bur...@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
[Bug fortran/45170] [F2003] allocatable character lengths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org 2010-11-02 22:32:26 UTC --- Parsing patch committed. TODO: Actual implementation; will probably done as follow up to PR 35810.
[Bug fortran/45170] [F2003] allocatable character lengths
--- Comment #4 from kargl at gcc dot gnu dot org 2010-08-15 18:46 --- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170
[Bug fortran/45170] [F2003] allocatable character lengths
--- Comment #3 from clerman at fuse dot net 2010-08-03 10:24 --- 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-bugzi...@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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170
[Bug fortran/45170] [F2003] allocatable character lengths
--- 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
