Bug 51961 - [OOP] ALLOCATE with MOLD= rejects if source-expr has a different rank
[OOP] ALLOCATE with MOLD= rejects if source-expr has a different rank
Status: NEW
Product: gcc
Classification: Unclassified
Component: fortran
4.7.0
: P3 normal
: ---
Assigned To: Not yet assigned to anyone
: rejects-valid
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-01-23 10:53 UTC by Tobias Burnus
Modified: 2013-01-08 15:37 UTC (History)
0 users

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2013-01-08 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tobias Burnus 2012-01-23 10:53:05 UTC
Fortran 2008 has:
  C638 (R626) Each allocate-object shall be type compatible (4.3.1.3) with
              source-expr. If SOURCE= appears, source-expr shall be a scalar or
              have the same rank as each allocate-object.

gfortran properly diagnoses this for SOURCE, but it also diagnoses it for MOLD= which is valid:

allocate (a(2), mold=b)   ! Valid
          2          1
Error: Source-expr at (1) must be scalar or have the same rank as the allocate-object at (2)



type t
end type t
class(T), allocatable :: a(:), b(:,:)
allocate(b(2,2))

allocate (a(2), source=b) ! Invalid - and correctly rejected
allocate (a(2), mold=b)   ! Valid - but not accepted
end
Comment 1 Dominique d'Humieres 2013-01-08 15:37:02 UTC
What is allocate supposed to do if the array and the mold are not
conformable?

From the 2008 draft:

Data usage and computation:

A structure constructor can omit the value for an allocatable component. 
SOURCE= in an ALLOCATE statement can give an array variable the bounds as
well as the value of an expression.
MOLD= in an ALLOCATE statement can give a polymorphic variable the shape,  
                                                                   ^^^^^
type,and type parameters of an expression without copying the value. 
The real and imaginary parts of a complex entity can be accessed
independently with a component-like syntax.  Intrinsic assignment to an
allocatable polymorphic variable is allowed.  A pointer function reference
can denote a variable in any variable definition context.  Some restrictions
on the use of dummy arguments in elemental subprograms have been removed.