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

[Bill Long]

On 3/20/12 11:22 AM, N.M. Maclaren wrote:
> 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!
>

Certainly a Fortran compiler is allowed to assume that a dummy argument 
is not aliased to an object of a different type.   Couldn't the C 
programmer pull off this crime more directly - just have a simple 
pointer to float as the dummy argument in the C function, and create a 
local pointer to int associated with the same memory and pass that to 
the next Fortran procedure corresponding to a dummy argument of type 
integer(c_int).  The compiler would assume that this integer dummy is 
not aliased to the original variable of type real(c_float) through 
argument association.

I'm inclined to say that someone who tries this deserves to have their 
program not work.

Cheers,
Bill


>>> 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.
>
>
> Regards,
> Nick Maclaren.
>
> _______________________________________________
> J3 mailing list
> J3 at j3-fortran.org
> http://j3-fortran.org/mailman/listinfo/j3

-- 
Bill Long                                           longb at cray.com
Fortran Technical Support    &                 voice: 651-605-9024
Bioinformatics Software Development            fax:   651-605-9142
Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101