[Patch, Fortran, OOP] PR 43388: [F2008] ALLOCATE with MOLD=

[Steve Kargl]

On Mon, Jun 14, 2010 at 06:33:04PM +0200, Janus Weil wrote:
> >> Unfortunately I don't have access to any other compiler supporting
> >> this feature (is there any?). Can someone check if NAG supports MOLD
> >> and if yes if it allows SOURCE together with MOLD?
> >
> > I cannot try NAG but I can try crayftn:
> >
> >
> > $ cat test.f90
> > integer, allocatable :: a, b, c
> > allocate (a, source=b)
> > allocate (a, mold=c)
> > allocate (a, source=b, mold=c)
> > end
> >
> > $ ftn test.f90
> > /opt/cray/xt-asyncpe/3.9/bin/ftn: INFO: linux target is being used
> >
> > allocate (a, source=b, mold=c)
> > ? ? ? ? ? ? ? ? ? ?^
> > ftn-1922 crayftn: ERROR $MAIN, File = test.f90, Line = 4, Column = 21
> > ?Only one source-expr may be specified for an ALLOCATE statement.
> 
> 
> Ok, since at least the Cray compiler and Dick Hendrickson (and Steve?)
> seem to support Tobias' interpretation that SOURCE and MOLD cannot
> appear together, I probably have to face the fact that my initial
> naive interpretation was incorrect.

I can understand your interpretation.  If one rewrites
C637 as

"At most one of apple and orange shall appear."

then it's clear an apple and an orange cannot be
used together.  This modified version does not suggest
to me that a "red apple" and "green apple" cannot
appear in an allocate statement.


> So, what does that mean for the implementation? One can argue that we
> don't need an expr4 if SOURCE and MOLD cannot appear together. But
> then, if I put either of them into expr3, what is the best way to
> distinguish between SOURCE and MOLD at resolution stage? I guess I
> could just put a one-bit flag 'mold' into gfc_code.ext.alloc. Any
> better ideas?

gfc_expr already has a few bit fields.  I'll suggest adding
'mold' there.

-- 
Steve