The following code
TYPE foo
INTEGER, DIMENSIN(:), PINTER :: array
END TYPE foo
type(foo),allocatable,dimension(:) :: mol
integer :: i, n
n = 10
ALLCATE (mol(n))
ALLCATE (mol(1)%array(5))
END
calls _gfortran_allocate_array for the second allocation, which
is wrong and can lead to segfault.
The problem is in gfc_array_allocate, where the check for
expr->symtree->n.sym->attr.allocatable
refers to mol, not to mol(1)%array.
This one is tricky.

Comment #1 from pinskia at gcc dot gnu dot org 2006-05-07 17:31
I wonder how related this is to PR 27411.

Comment #2 from tkoenig at gcc dot gnu dot org 2006-05-07 19:36
(In reply to comment #1)
I wonder how related this is to PR 27411.

As far as I can see, there's no relationship. To my eye, this looks
like a stand-alone bug :-)

Summary of what goes wrong:

gfc_array_allocate needs to differentiate between pointer and
allocatable arrays because it needs to call _gfortran_allocate_array for
allocatable arrays and _gfortran_allocate for pointers. The difference
is that, for an allocatable array, it is an error if the allocatable
array is already allocated. For pointers, it's ok (it potentially
leaks memory, though).

The test wether this is an allocatable array is done via

expr->symtree->n.sym->attr.allocatable, which is fine for non-derived
types. The test case exposes a problem, that "mol" is allocatable,
mol%array is a pointer, and what we get via expr->symtree-is
the array and not the pointer. Apparently, we need to look somewhere
else for that information, but I haven't found out where yet.

Here is a test case which actually provokes a runtime error:

TYPE foo
INTEGER, DIMENSIN(:), PINTER :: array
END TYPE foo

type(foo),allocatable,dimension(:) :: mol

ALLCATE (mol(1))
mol = transfer(-1, mol) ! Initialize the array with garbage
ALLCATE (mol(1)%array(5)) ! Fails with "Attempting to allocate already
allocated array"

END

Comment #3 from tkoenig at gcc dot gnu dot org 2006-05-08 21:06
Here's a test case that does not require transfer:

TYPE foo
INTEGER, DIMENSIN(:), PINTER :: array
END TYPE foo

type(foo),allocatable,dimension(:) :: mol

ALLCATE (mol(1))
ALLCATE (mol(1)%array(5))
ALLCATE (mol(1)%array(5))

END

This shouldn't error out with "Attempting to allocate already allocated array".

Comment #4 from tkoenig at gcc dot gnu dot org 2006-05-08 21:59
Created an attachment (id=11415)
()
patch
This fixes the regression. It isn't pretty, because it would need
to be changed as part of an implementation of allocatable components.

Comment #5 from tkoenig at gcc dot gnu dot org 2006-05-08 22:11
Created an attachment (id=11416)
()
better patch
Forgot to initialize a variable in the earlier attempt.
This one looks K.

Comment #6 from tkoenig at gcc dot gnu dot org 2006-05-10 18:27
Subject: Bug 27470

Author: tkoenig
Date: Wed May 10 18:26:51 2006
New Revision: 113680

URL:
Log:
2005-05-10 Thomas Koenig <Thomas.Koenig (AT) online (DOT) de>

PR fortran/27470
* trans-array.c(gfc_array_allocate): If ref->next exists
that is if there is a statement like ALLCATE(foo%bar(2)),
F95 rules require that bar should be a pointer.

2005-05-10 Thomas Koenig <Thomas.Koenig (AT) online (DOT) de>

PR fortran/27470
* New test case.

Added:

Modified:
trunk/gcc/fortran/ChangeLog

trunk/gcc/testsuite/ChangeLog

Comment #7 from mmitchel at gcc dot gnu dot org 2006-05-14 22:34
P5: F95 is not release-critical.

Comment #8 from patchapp at dberlin dot org 2006-05-15 19:38
Subject: Bug number PR 27470
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is

Comment #9 from mmitchel at gcc dot gnu dot org 2006-05-25 02:36
Will not be fixed in 4.1.1; adjust target milestone to 4.1.2.

Comment #10 from tkoenig at gcc dot gnu dot org 2006-05-27 21:25
I applied the patch to the 4.1 branch, and I have a strange "regression":

When running "make check-fortran", I get

Running target unix
Using / as board description file for
target.
Using / as generic interface file for target.
Using /
as tool-and-target-specific interface file.
Running /

FAIL: (test for errors, line 61)
FAIL: (test for excess errors)
got a INT signal, interrupted by user

gfortran Summary

# of expected passes 6807
# of unexpected failures 2
# of expected failures 11
# of unsupported tests 16

(although it is hard to see how that came about).

When I run just that test case, I get

$ make -k check-gfortran RUNTESTFLAGS=""
test -d testsuite || mkdir testsuite
test -d testsuite/gfortran || mkdir testsuite/gfortran
(rootme=`${PWDCMD-pwd}`; export rootme; \
srcdir=`cd ; ${PWDCMD-pwd}`
; export srcdir ; \
cd testsuite/gfortran; \
rm -f tmp-site.exp; \
sed '/set tmpdir/ s|testsuite|testsuite/gfortran|' \
< //site.exp tmp-site.exp; \
/bin/sh ${srcdir}//move-if-change tmp-site.exp site.exp; \
EXPECT=`if [ -f ${rootme}//expect/expect ] ; then echo
${rootme}//expect/expect ; else echo expect ; fi` ; export EXPECT ; \
if [ -f ${rootme}//expect/expect ] ; then \
TCL_LIBRARY=`cd ; cd ${srcdir}//tcl/library ; ${PWDCMD-pwd}` ;
\
export TCL_LIBRARY ; fi ; \
`if [ -f ${srcdir}//dejagnu/runtest ] ; then echo
${srcdir}//dejagnu/runtest ; else echo runtest; fi` gfortran
)
site.exp is unchanged
Test Run By ig25 on Sat May 27 23:22:53 2006
Native configuration is i686-pc-linux-gnu

gfortran tests

Schedule of variations:
unix

Running target unix
Using / as board description file for
target.
Using / as generic interface file for target.
Using /
as tool-and-target-specific interface file.
Running /

gfortran Summary

# of expected passes 18
/
version 4.1.2 20060527 (prerelease)

Not committing right now.

Comment #11 from tkoenig at gcc dot gnu dot org 2006-05-28 12:33
(In reply to comment #10)

Not committing right now.

Downloading a fresh version via svn cured that problem.

I'd have commited the patch by now, but for some strange reason,
I get "Authentication failed" errors with svn, and my E-Mails to
the gcc and fortran mailing lists also don't go through.

Comment #12 from tkoenig at gcc dot gnu dot org 2006-05-28 20:36
Subject: Bug 27470

Author: tkoenig
Date: Sun May 28 20:35:53 2006
New Revision: 114176

URL:
Log:
2005-05-28 Thomas Koenig <Thomas.Koenig (AT) online (DOT) de>

PR fortran/27470
Backport from trunk.
* trans-array.c(gfc_array_allocate): If ref->next exists
that is if there is a statement like ALLCATE(foo%bar(2)),
F95 rules require that bar should be a pointer.

2005-05-28 Thomas Koenig <Thomas.Koenig (AT) online (DOT) de>

PR fortran/27470
Backport from trunk.
* New test case.

Added:

Modified:

Comment #13 from tkoenig at gcc dot gnu dot org 2006-05-28 20:37
Fixed on trunk and 4.1.
Closing.

Comment #14 from jjcogliati-r1 at yahoo dot com 2006-06-28 18:02
This works in 4.1.0, so only 4.1.1 has this bug so far as I can tell.