public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/57833] New: MOVE_ALLOC's TO actual argument cannot be used in subsequent ALLOCATE statement
@ 2013-07-05 19:38 jwmwalrus at gmail dot com
  2013-07-05 20:19 ` [Bug fortran/57833] " anlauf at gmx dot de
  2013-07-06  7:00 ` [Bug fortran/57833] Bogus "must not appear in the array specification ... in the same ALLOCATE statement" when used in the specification expression the bounds var burnus at gcc dot gnu.org
  0 siblings, 2 replies; 3+ messages in thread
From: jwmwalrus at gmail dot com @ 2013-07-05 19:38 UTC (permalink / raw)
  To: gcc-bugs

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

            Bug ID: 57833
           Summary: MOVE_ALLOC's TO actual argument cannot be used in
                    subsequent ALLOCATE statement
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jwmwalrus at gmail dot com

The following throws an error in both gfortran 4.8 and 4.9, and it shouldn't.

module mod1

contains
    pure subroutine expand_array(array)
        character(*), allocatable, intent(INOUT) :: array(:)
        character(LEN(array)), allocatable :: aux(:)

        if (ALLOCATED(array)) then
            call MOVE_ALLOC(array, aux)

            allocate (array(SIZE(aux) + 1))

            array(:SIZE(aux)) = aux

            deallocate (aux)
        else
            allocate (array(1))
        endif

    end subroutine

end module

The actual output is:

...:~$ gfortran-4.9 -c test_move_alloc.f90 
test_move_alloc.f90:11.27:

            allocate (array(SIZE(aux) + 1))
                           1
Error: 'array' must not appear in the array specification at (1) in the same
ALLOCATE statement where it is itself allocated

The info for gfortran 4.8 and 4.9 is:

...:~$ ll `which gfortran-4.9` && /usr/lib/gcc-snapshot/bin/gfortran -v &&
apt-cache policy gfortran-4.8 gcc-snapshot && lsb_release -rd
lrwxrwxrwx 1 root staff 34 Jul  5 12:58 /usr/local/bin/gfortran-4.9 ->
/usr/lib/gcc-snapshot/bin/gfortran*
Using built-in specs.
COLLECT_GCC=/usr/lib/gcc-snapshot/bin/gfortran
COLLECT_LTO_WRAPPER=/usr/lib/gcc-snapshot/libexec/gcc/x86_64-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 20130620-1'
--with-bugurl=file:///usr/share/doc/gcc-snapshot/README.Bugs
--enable-languages=c,ada,c++,java,go,fortran,objc,obj-c++
--prefix=/usr/lib/gcc-snapshot --enable-shared --enable-linker-build-id
--disable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-snap-amd64/jre
--enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-snap-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-snap-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --with-tune=generic --disable-werror
--enable-checking=yes --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.0 20130620 (experimental) [trunk revision 200244] (Debian
20130620-1) 
gfortran-4.8:
  Installed: 4.8.1-5
  Candidate: 4.8.1-5
  Version table:
 *** 4.8.1-5 0
        200 http://ftp.us.debian.org/debian/ unstable/main amd64 Packages
        100 /var/lib/dpkg/status
     4.8.1-2 0
        500 http://ftp.us.debian.org/debian/ testing/main amd64 Packages
gcc-snapshot:
  Installed: 20130620-1
  Candidate: 20130620-1
  Version table:
 *** 20130620-1 0
        200 http://ftp.us.debian.org/debian/ unstable/main amd64 Packages
        100 /var/lib/dpkg/status
Description:    Debian GNU/Linux testing (jessie)
Release:    testing


^ permalink raw reply	[flat|nested] 3+ messages in thread

* [Bug fortran/57833] MOVE_ALLOC's TO actual argument cannot be used in subsequent ALLOCATE statement
  2013-07-05 19:38 [Bug fortran/57833] New: MOVE_ALLOC's TO actual argument cannot be used in subsequent ALLOCATE statement jwmwalrus at gmail dot com
@ 2013-07-05 20:19 ` anlauf at gmx dot de
  2013-07-06  7:00 ` [Bug fortran/57833] Bogus "must not appear in the array specification ... in the same ALLOCATE statement" when used in the specification expression the bounds var burnus at gcc dot gnu.org
  1 sibling, 0 replies; 3+ messages in thread
From: anlauf at gmx dot de @ 2013-07-05 20:19 UTC (permalink / raw)
  To: gcc-bugs

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

Harald Anlauf <anlauf at gmx dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |anlauf at gmx dot de

--- Comment #1 from Harald Anlauf <anlauf at gmx dot de> ---
(In reply to John from comment #0)

Confirmed.  The example works with ifort 13 and nagfor.

All gfortran versions since 4.3 produce the same error,
while 4.1 did not consider MOVE_ALLOC as a pure intrinsic.


^ permalink raw reply	[flat|nested] 3+ messages in thread

* [Bug fortran/57833] Bogus "must not appear in the array specification ... in the same ALLOCATE statement" when used in the specification expression the bounds var
  2013-07-05 19:38 [Bug fortran/57833] New: MOVE_ALLOC's TO actual argument cannot be used in subsequent ALLOCATE statement jwmwalrus at gmail dot com
  2013-07-05 20:19 ` [Bug fortran/57833] " anlauf at gmx dot de
@ 2013-07-06  7:00 ` burnus at gcc dot gnu.org
  1 sibling, 0 replies; 3+ messages in thread
From: burnus at gcc dot gnu.org @ 2013-07-06  7:00 UTC (permalink / raw)
  To: gcc-bugs

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |rejects-valid
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-07-06
                 CC|                            |burnus at gcc dot gnu.org
            Summary|MOVE_ALLOC's TO actual      |Bogus "must not appear in
                   |argument cannot be used in  |the array specification ...
                   |subsequent ALLOCATE         |in the same ALLOCATE
                   |statement                   |statement" when used in the
                   |                            |specification expression
                   |                            |the bounds var
     Ever confirmed|0                           |1
      Known to fail|                            |4.3.4, 4.8.1, 4.9.0

--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> ---
    pure subroutine expand_array(array)
        character(*), allocatable, intent(INOUT) :: array(:)
        character(LEN(array)), allocatable :: aux(:)

            allocate (array(SIZE(aux) + 1))

The problem is that AUX depends on a specification expression involving ARRAY;
while valid, it confuses the is-the-same-expression-used check.


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2013-07-06  7:00 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-07-05 19:38 [Bug fortran/57833] New: MOVE_ALLOC's TO actual argument cannot be used in subsequent ALLOCATE statement jwmwalrus at gmail dot com
2013-07-05 20:19 ` [Bug fortran/57833] " anlauf at gmx dot de
2013-07-06  7:00 ` [Bug fortran/57833] Bogus "must not appear in the array specification ... in the same ALLOCATE statement" when used in the specification expression the bounds var burnus at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).