From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3317 invoked by alias); 30 Dec 2012 10:42:16 -0000 Received: (qmail 3301 invoked by uid 22791); 30 Dec 2012 10:42:16 -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 mx02.qsc.de (HELO mx02.qsc.de) (213.148.130.14) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 30 Dec 2012 10:42:07 +0000 Received: from archimedes.net-b.de (port-92-195-100-21.dynamic.qsc.de [92.195.100.21]) by mx02.qsc.de (Postfix) with ESMTP id 2FB2227724; Sun, 30 Dec 2012 11:42:05 +0100 (CET) Message-ID: <50E01A7C.2090106@net-b.de> Date: Sun, 30 Dec 2012 10:42: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> 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: 2012-12/txt/msg01477.txt.bz2 Janne Blomqvist wrote: > On Fri, Dec 28, 2012 at 12:31 AM, Tobias Burnus wrote: >> a) The Fortran standard only defines LOGICAL(kind=C_Bool) as being >> interoperable with C - no other LOGICAL type. That matches GCC: With gcc >> (the C compiler) only _Bool is a BOOLEAN_TYPE with TYPE_PRECISION == 1. >> Hence, this patch rejects other logical kinds as dummy argument/result >> variable in BIND(C) procedures if -std=f2003/f2008/f2008ts is specified >> (using -pedantic, one gets a warning). > Sorry, I don't understand, what is the -pedantic warning about if it's > already rejected? Or do you mean std=gnu -pedantic? The latter. Actually, I use "gfc_notify_std(GFC_STD_GNU, ..." and just observed the -pedantic result. (I have to admit that I never quite understood - and still don't - what -pedantic exactly does.) >> b) As GNU extension, other logical kinds are accepted in BIND(C) procedures; >> however, as the main use of "LOGICAL(kind=4)" (for BIND(C) procedures) is to >> handle logical expressions which use C's int, one has to deal with all >> integer values and not only 0 and 1. Hence, a normal integer type is used >> internally in that case. That has been done to avoid surprises of users and >> hard to trace bugs. > Does this actually work robustly? I think it does in the sense that it mitigates the problems related to LOGICAL(kind=4) and BIND(C) procedures. No, if one thinks of it as full cure for the problem. The only way to ensure this is to turn all of gfortran's LOGICALs into integers - and even that won't prevent issues related to interoperability with C's _Bool as that one expects only 0 and 1. Thus, either C<->Fortran or Fortran <-> Fortran logical(kind=C_Bool) could still lead to problems. > E.g. if you have a logical but really integer under the covers, what happens if you equivalence it with a "normal" logical variable. Well, equivalencing of actual arguments / result variables is not allowed (I think, not checked). Besides, if you have equivalenced two variables, if you have set one, you may not access the other, e.g.: logical :: A integer :: B equivalence (A,B) A = .true. B = 1 if (A) ... is invalid as "A" is not defined, even if A = .true. and B = 1 have exactly the same storage size and bit patterns and, hence, in practice "A" would be a well defined .true. > Or pass it as an argument to a procedure expecting a normal logical etc. If the value is only 1 or 0, there shouldn't be any problems. Only if one uses in turn ".not. dummy" there might be one. The idea of the patch was only to mitigate the problems - a full cure is not possible (cf. above). I think the most likely problematic code is if (.not. c_function()) which is fixed by the patch. And the hope is that fold-converting to a type-precision=1, Boolean-type logical fixes most of the remaining issues. I think the current solution which only affects non-C_BOOL-kind actual arguments and result variables of BIND(C) procedures is a good compromise. * * * But if others do not like this approach, one could turn the gfc_notify_std into a gfc_error are completely reject logicals with kinds /= C_Bool for dummy arguments/result variables in BIND(C) procedures. Would you prefer that approach? (Doing so will break user code (e.g. Open MPI) and make users unhappy but it will be a tad safer as the current patch.) Tobias