Bug 51961 - [OOP] ALLOCATE with MOLD= rejects if source-expr has a different rank
Summary: [OOP] ALLOCATE with MOLD= rejects if source-expr has a different rank
Status: WAITING
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.7.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: rejects-valid
Depends on:
Blocks:
 
Reported: 2012-01-23 10:53 UTC by Tobias Burnus
Modified: 2019-04-08 17:16 UTC (History)
1 user (show)

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.
Comment 2 Dominique d'Humieres 2019-04-06 12:40:29 UTC
> What is allocate supposed to do if the array and the mold are not
> conformable?

No answer after more than six years!-(Shall I close the PR as INVALID to get one?).
Comment 3 janus 2019-04-08 17:16:03 UTC
(In reply to Dominique d'Humieres from comment #1)
> What is allocate supposed to do if the array and the mold are not
> conformable?

AFAICS the mold expr is normally only used for the type, provided the shape of the allocate-object is specified explicitly, as in Tobias' example:

allocate (a(2), mold=b)   ! Valid - but not accepted

I tend to agree that this might be valid. Then 'a' should be allocated with two elements and using the type from 'b'.


However, if the shape is not specified explicitly, then it can be taken from the source-expr (therefore the rank needs to agree) as in this example:

allocate (a, mold=b)      ! correctly rejected?

From F08 section 9.7.1.2:

When an ALLOCATE statement is executed for an array with no allocate-shape-spec-list, the bounds of source-expr determine the bounds of the array. Subsequent changes to the bounds of source-expr do not affect the array bounds.

I would conclude that this second case is invalid, however this is not reflected in C638, which might possibly be an oversight in Fortran 2008. AFAICS Fortran 2018 changes nothing in this regard.