(j3.2006) (SC22WG5.4671) [ukfortran] AW: Informal WG5 ballot on new draft DTS
Tue Mar 20 13:45:24 EDT 2012
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
>>> 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
I'm inclined to say that someone who tries this deserves to have their
program not work.
>>> For example, creating a logical descriptor from one passed as a complex
>>> descriptor. That's quite legal in C but, because EQUIVALENCE is
>>> 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.
> J3 mailing list
> J3 at j3-fortran.org
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
More information about the J3