Bug 51055 - deferred length character allocation: allocate(character(len=i)::s) rejected
deferred length character allocation: allocate(character(len=i)::s) rejected
Status: RESOLVED FIXED
Product: gcc
Classification: Unclassified
Component: fortran
4.7.0
: P3 normal
: ---
Assigned To: Not yet assigned to anyone
: rejects-valid, wrong-code
Depends on:
Blocks: 45170
  Show dependency treegraph
 
Reported: 2011-11-09 11:47 UTC by jpr
Modified: 2012-05-23 20:38 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2012-05-14 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description jpr 2011-11-09 11:47:58 UTC
Hi,

I think the program below is valid, but rejected by gfortran 


program a
  character(len=:), allocatable :: s
  integer :: i=10
  allocate(character(len=i)::s)
end program a


gfortran -v -o s s.f90
Driving: gfortran -v -o s s.f90 -l gfortran -l m -shared-libgcc
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/wrk/jpr/gcc-4.7/bin/../libexec/gcc/i686-pc-linux-gnu/4.7.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../gcc/configure --enable-languages=c,c++,fortran --disable-bootstrap --prefix=/wrk/jpr/gcc-4.7 --with-gmp=/wrk/jpr/extralib --with-mpfr=/wrk/jpr/extralib
Thread model: posix
gcc version 4.7.0 20110927 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-o' 's' '-shared-libgcc' '-mtune=generic' '-march=pentiumpro'
 /home/wrk/jpr/gcc-4.7/bin/../libexec/gcc/i686-pc-linux-gnu/4.7.0/f951 s.f90 -quiet -dumpbase s.f90 -mtune=generic -march=pentiumpro -auxbase s -version -fintrinsic-modules-path /home/wrk/jpr/gcc-4.7/bin/../lib/gcc/i686-pc-linux-gnu/4.7.0/finclude -o /tmp/cc1PUv7g.s
GNU Fortran (GCC) version 4.7.0 20110927 (experimental) (i686-pc-linux-gnu)
        compiled by GNU C version 3.4.6 20060404 (Red Hat 3.4.6-11), GMP version 4.3.1, MPFR version 2.4.1, MPC version 0.8
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU Fortran (GCC) version 4.7.0 20110927 (experimental) (i686-pc-linux-gnu)
        compiled by GNU C version 3.4.6 20060404 (Red Hat 3.4.6-11), GMP version 4.3.1, MPFR version 2.4.1, MPC version 0.8
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
s.f90:4.25:

  allocate(character(len=i)::s)
                         1
Error: Variable 'i' cannot appear in the expression at (1)
Comment 1 Tobias Burnus 2011-11-09 12:45:25 UTC
I also think that it is valid. However, I think there is already some bugreport about this issue.

Stupid workaround: Replace
  allocate(character(len=i)::s)
by
  s = repeat(' ', i)
Comment 2 jpr 2011-11-10 06:09:07 UTC
OK, i found and lost the PR that included this. However, 
your workaround doesn't seem to work either:

program a
 character(len=:),allocatable::s
 integer::j=2
 s=repeat(' ',j)
 print*,len(s),len(repeat(' ',j))
end program a

gfortran -o a a.f90; ./a
     2846708           2
Comment 3 Tobias Burnus 2011-11-10 08:20:12 UTC
(In reply to comment #2)
> However, your workaround doesn't seem to work either:
>  s=repeat(' ',j)

Try: s = (repeat(' ', j)

I think the issue is somewhat covered in PR 45170 comment 14
Comment 4 Tobias Burnus 2012-05-11 14:31:26 UTC
See http://gcc.gnu.org/ml/fortran/2012-05/msg00054.html


The problem is that the character length is used for reallocation before it is set.

The following should work. The only question is whether it causes problems by enabling not only REPEAT but all other functions.

Well, seemingly also other functions are affected. The following code has the same problem.

The bug is also mentioned in:
 PR 49110
 PR 45170 comment 14 (mentioned there and in some other comments, but not the bug)
Comment 5 Tobias Burnus 2012-05-14 16:45:31 UTC
Author: burnus
Date: Mon May 14 16:45:16 2012
New Revision: 187472

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

        PR fortran/49110
        PR fortran/51055
        PR fortran/53329
        * trans-expr.c (gfc_trans_assignment_1): Fix allocation
        handling for assignment of function results to allocatable
        deferred-length strings.
        * trans-decl.c (gfc_create_string_length): For deferred-length
        module variables, include module name in the assembler name.
        (gfc_get_symbol_decl): Don't override the assembler name.

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

        PR fortran/49110
        PR fortran/51055
        PR fortran/53329
        * gfortran.dg/deferred_type_param_4.f90: New.
        * gfortran.dg/deferred_type_param_6.f90: New.


Added:
    trunk/gcc/testsuite/gfortran.dg/deferred_type_param_4.f90
    trunk/gcc/testsuite/gfortran.dg/deferred_type_param_6.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-decl.c
    trunk/gcc/fortran/trans-expr.c
    trunk/gcc/testsuite/ChangeLog
Comment 6 Tobias Burnus 2012-05-14 16:48:06 UTC
The REPEAT issue is now fixed. Thus, one can replace the work-around-around "(repeat(...))" by the work-around "repeat(...)".


TODO: The issue shown in comment 0 and in the summary of this PR.

(Which is the same as PR 45170 comment 14. For quotes from the standard, see that PR.)
Comment 7 Tobias Burnus 2012-05-23 20:35:44 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 8 Tobias Burnus 2012-05-23 20:38:49 UTC
(In reply to comment #6)
> TODO: The issue shown in comment 0 and in the summary of this PR.

That's now also FIXED on the 4.8 trunk.

Thanks for the bug report - and sorry for taking half a year to get this fixed.