(j3.2006) TS18508: CO_REDUCE - and allocatable/pointer components

John Reid John.Reid
Thu Apr 10 06:34:37 EDT 2014

The same considerations apply to CO_BROADCAST and this is a simpler one 
to consider. We need to say that any pointer components of the broadcast 
values are undefined.


Malcolm Cohen wrote:
> <<<
> When I think of an implementation, I would transfer on one image the variable of
> a remote image and then invoke the intrinsic function using the local and the
> fetched variable.
> However, the fetching of the variable becomes way more complicated when the
> SOURCE= argument is permitted to be a derived type with allocatable and - in
> particular - pointer components. Those components could also be polymorphic
> which makes things even more complicated.
> No, the pointer components are almost trivial.  I don't see how polymorphic
> enters into it.  Associated pointer components from a remote image are
> undefined, so the "fetch" produces a value whose pointer components are either
> disassociated (the only good case) or undefined.
> So just blat the bits of the pointer component across, and when the world blows
> up in the user's face say "your bug".
> The only case where a pointer component might not be undefined would be where
> the image looking at the result is looking at one that is the result of calling
> the function on that image.  Since CO_REDUCE doesn't say which images execute
> the function references, it would seem impossible to rely on in any case.
> It *might* be worth actually saying right out that any pointer components of the
> result of CO_REDUCE will be disassociated or undefined.
> Cheers,

More information about the J3 mailing list