(j3.2006) (SC22WG5.4668) [ukfortran] AW: Informal WG5 ballot on new draft DTS

N.M. Maclaren nmm1
Tue Mar 20 12:22:22 EDT 2012

On Mar 20 2012, Bill Long wrote:
>>> As the person to blame for perpetrating that vague evasion, let me try
>>> to explain why I did it :-(
>> Oops. That may still be confusing. I was trying to address Reinhold's
>> concern, only more generally. It isn't JUST the modification of
>> descriptors in other ways, but the creating of perfectly valid C pointers
>> and then creating a new descriptor from them. If this ends up creating
>> two Fortran objects that the Fortran compiler 'knows' are distinct but
>> aren't, chaos will sometimes ensue.
>Unless this second object is accessible in Fortran by, for example, 
>being associated with an argument in a call to a Fortran procedure, the 
>newly created descriptor could be harmless.   But I think the descriptor 
>issue is an extra complication here - equally bad mischief is possible 
>with ordinary pointers.

Not really.  I am thinking of Fortran creating a (say) complex object
with the target attribute, passing it to C, and that calling Fortran
with a logical argument with the pointer attribute, in a context where
the original object is visible.  Because a logical pointer can't refer
to a complex target in Fortran (can it?), it could optimise on the basis
of that assumption.  Bang!

>> For example, creating a logical descriptor from one passed as a complex
>> descriptor. That's quite legal in C but, because EQUIVALENCE is forbidden
>> for arguments, optimising compilers may assume that it can't happen in
>> that way.
>As long as the new descriptor is localized to the C function, the 
>compiler that matters is the C compiler, which is not that optimizing.

Yes.  That's not the problem.

Nick Maclaren.

More information about the J3 mailing list