From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8449 invoked by alias); 8 Jan 2013 22:34:50 -0000 Received: (qmail 8312 invoked by uid 22791); 8 Jan 2013 22:34:48 -0000 X-SWARE-Spam-Status: No, hits=-2.9 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_DNSWL_NONE X-Spam-Check-By: sourceware.org Received: from mx01.qsc.de (HELO mx01.qsc.de) (213.148.129.14) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 08 Jan 2013 22:34:41 +0000 Received: from archimedes.net-b.de (port-92-195-81-4.dynamic.qsc.de [92.195.81.4]) by mx01.qsc.de (Postfix) with ESMTP id 511033CA70; Tue, 8 Jan 2013 23:34:39 +0100 (CET) Message-ID: <50EC9EFF.8020706@net-b.de> Date: Tue, 08 Jan 2013 22:34:00 -0000 From: Tobias Burnus User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Janne Blomqvist CC: gcc patches , gfortran Subject: Re: [Patch, Fortran] PR55758 - Non-C_Bool handling with BIND(C) References: <50DCCC29.6010206@net-b.de> <50E01A7C.2090106@net-b.de> <50E9ABC7.4040705@net-b.de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2013-01/txt/msg00454.txt.bz2 Janne Blomqvist worte: > On Sun, Jan 6, 2013 at 6:52 PM, Tobias Burnus wrote: >> >Attached is a small variation, which in addition handles the case that a >> >non-BOOL_C LOGICAL, Bind(C) dummy argument (or result variable) is used in a >> >procedure call. In that case, the variable is now converted to a >> >TYPE_PRECISION == 1 variable. -- The updated patch was build and regtested >> >successfully. > Nice, this should fix a pitfall with the previous patch. I still worry > about these almost-but-not-quite logicals causing weird and very hard > to track down bugs. Though, it should be much less severe then with the current trunk. > A slightly safer variant of the approach youdescribe above would be to convert the variable directly after the bind(c) procedure call; that should make it pretty fool-proof, AFAICS? > (in some cases that would be a bit of extra useless work, but I doubt > it would matter performance-wise). Well, that's not at trivial as it sounds. In particular for a Fortran-written procedure, which gets the input from C. If the variable is INTENT(IN) or if it is not modified in the procedure, it may not be touched. In order to do this, one has to implement support for a shadow variable, which has to set the real one at the end of the procedure. I don't think that this shadow-var handling is really that trivial. For actual arguments, doing the conversion back is simpler. Function results might be also a bit tricky, but that's mostly handled by the current patch, I hope. Tobias