From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Tue Mar 20 18:51:41 2012 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www.open-std.org Received: by www.open-std.org (Postfix, from userid 521) id 048F1356941; Tue, 20 Mar 2012 18:51:40 +0100 (CET) Delivered-To: sc22wg5@open-std.org Received: from exprod6og113.obsmtp.com (exprod6og113.obsmtp.com [64.18.1.31]) by www.open-std.org (Postfix) with ESMTP id 33C8E35693F for ; Tue, 20 Mar 2012 18:51:39 +0100 (CET) Received: from CFWEX01.americas.cray.com ([136.162.34.11]) (using TLSv1) by exprod6ob113.postini.com ([64.18.5.12]) with SMTP ID DSNKT2jDqjDVjpEzmAvOVJf2aODSQtQqdQqK@postini.com; Tue, 20 Mar 2012 10:51:40 PDT Received: from fortran.us.cray.com (172.31.19.200) by CFWEX01.americas.cray.com (172.30.88.25) with Microsoft SMTP Server id 14.1.355.2; Tue, 20 Mar 2012 12:45:12 -0500 Message-ID: <4F68C234.7010009@cray.com> Date: Tue, 20 Mar 2012 12:45:24 -0500 From: Bill Long Reply-To: Organization: Cray Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: sc22wg5 Subject: Re: (j3.2006) (SC22WG5.4668) [ukfortran] AW: Informal WG5 ballot on new draft DTS References: <20120219131214.268A1356998@www.open-std.org> <20120319050226.88C14356822@www.open-std.org> <20120319134001.616DE356854@www.open-std.org> <20120320131906.BBAC53568F0@www.open-std.org> <20120320152833.62F5B356940@www.open-std.org> <20120320162223.B0B8035693F@www.open-std.org> In-Reply-To: <20120320162223.B0B8035693F@www.open-std.org> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-sc22wg5@open-std.org Precedence: bulk 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@j3-fortran.org > http://j3-fortran.org/mailman/listinfo/j3 -- Bill Long longb@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