[J3] [BULK] Re: [EXTERNAL] Complex pointer to real array and vice-versa

[Brad Richardson]

My reading is that there is a very subtle way in which the rules are
not quite sufficient to guarantee correct data interpretation of
storage sequence association between real and complex arrays of all
kinds, but all sane (and actual as far as I know) implementations would
work. This would fully close off the possibilities of using alternate
data layout/interpretation strategies, but I don't think that's really
going to negatively impact anyone.

My hesitation for the proposal is that it is a subtle violation of the
type-safety of the language, but just barely and it is well
constrained. That's just the purist in me talking though, so it's by no
means a strong objection.

Regards,
Brad

On Thu, 2024-04-25 at 13:19 +0000, Clune, Thomas L. \(GSFC-6101\) via
J3 wrote:
> 
> 
> 
> I think the requirement for COMPLEX and REAL storage association is
> stronger than you have suggested:
>  
> 19.5.3.2:    …  (2) a nonpointer scalar object that is double
> precision real or default complex occupies two contiguous numeric
> storage units,
>  
>  
> 
> 
> 
> 
> 
> 
> 
> From: J3 <j3-bounces at mailman.j3-fortran.org> on behalf of Pierre
> Hugonnet via J3 <j3 at mailman.j3-fortran.org>
> Date: Wednesday, April 24, 2024 at 4:41 PM
> To: Van Snyder via J3 <j3 at mailman.j3-fortran.org>
> Cc: Pierre Hugonnet <pieru at ugo235.fr>
> Subject: [BULK] Re: [J3] [EXTERNAL] Complex pointer to real array and
> vice-versa
> CAUTION: This email originated from outside of NASA.  Please take
> care when clicking links or opening attachments.  Use the "Report
> Message" button to report suspicious messages to the NASA SOC.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> Hello,
> 
> 
> Le 23/04/2024 à 21:55, Van Snyder via J3 a écrit : 
> 
> > Specific comments on the paper:
> > 
> > Section 3.1 need not mention the "target or the pointer attribute"
> > because pointers have the target attribute.
> 
> 
> In `c => r` (or any alternative syntax), `r` is not necessarily a
> pointer array, it can be a static array, an allocatable array, etc...
> So it seems to me that "... with the target or the pointer attribute"
> is correct. But maybe I didn't catch your point...
> 
> 
> > 
> > Section 4.1 would not constrain the memory layout any more than
> > equivalence already does. The required layout does not "seem to be
> > the de-facto standard." It's what's already required to make
> > equivalence work.
> 
> Well, yes and no... EQUIVALENCE is defined for the default complex
> type only, and anything could happen with the other kinds. If a
> compiler stores the `double precision` type on 8 bytes, I think that
> nothing in the standard would disallow storing a `complex(kind(1d0))`
> on 20 bytes for instance. I doubt any past or existing compiler did
> or does that, but it would be allowed.
> 
> Also, and even for the default complex type, I think that the current
> standard allows storing the imaginary part first, and the real part
> second. With the new proposal, the real part would necessarily come
> first (which is the "de facto standard" anyway).
> 
> 
> 
> > 
> > 
> > Yeah, people want to eliminate storage association, but it's still
> > in the standard. This proposal would be concistent with it, and
> > would not change it.
> 
> My personal opinion is that storage association can still make sense
> in some cases in HPC (typically when dealing with large/huge data
> volumes) 
> 
> 
>  
> 
> 
>  
> 
> 
> Regards
> 
> 
>