(j3.2006) (SC22WG5.3766) Ballot on the technical content of the TR

Craig Rasmussen crasmussen
Mon Dec 8 13:51:26 EST 2008

On Dec 8, 2008, at 10:57 AM, Aleksandar Donev wrote:

> On Sunday 07 December 2008 18:46, Jim Xia wrote:
>>  Furthermore allowing
>> updates on Fortran descriptors from C programs will likely cause
>> safety issues and also be problematic in consistency check by some
>> vendors.  This becomes a sure way to introduce bugs difficult to
>> diagnose.
> I do not understand this. You don't want a descriptor TR at all or  
> not?
> You want something that is "safe"---can you propose such a design
> please? I find it impossible to imagine how C can pass things to
> Fortran by descriptor without being allowed to modify the  
> descriptor???
> Perhaps you have something else in mind, but the above does not make
> sense.

HPC developers are currently using libraries that successfully access  
dope vectors from Fortran now.  The primary difficulty is that there  
is no standard way to do this.  Some vendors publish dope vector  
information and others won't release it as they want to be able to  
change dope vectors without affecting user code, in which case, the  
dope vector information must be reverse engineered.  The TR will  
provide a standard way to access dope vectors that is MUCH MORE SAFE  
than current practice and will not change when a vendor releases a new  
version of their compiler (oh, I'm sorry, of their processor :-).


More information about the J3 mailing list