[Patch, Fortran] PR55758 - Non-C_Bool handling with BIND(C)
Tobias Burnus
burnus@net-b.de
Sun Jan 6 16:52:00 GMT 2013
** ping **
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.
As written before, I believe that the patch avoids some pitfalls with C
interoperability of logical variables: On one hand, it improves
cross-compiler portability by rejecting non C_BOOL ones with
-std=f2003/f2008/f2008ts; on the other hand, it makes wrong-code issues
due to using non-0/1 integers from C much less likely. In both cases,
the type-precision==1 handling for non-BIND(C) Fortran LOGICALs or for
Bind(C) LOGICAL(kind=C_BOOL) remains the same; hence, no optimization
issue is caused.
OK for the trunk?
Tobias
PS: If there is consensus that this patch is a bad idea, I propose to
reject non-C_BOOL LOGICALs unconditionally as dummy argument or result
variable of BIND(C) procedures. Or do you have a better suggestion?
On December 30, 2012, Tobias Burnus wrote:
> Janne Blomqvist wrote:
>> On Fri, Dec 28, 2012 at 12:31 AM, Tobias Burnus <burnus@net-b.de> 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
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: c-bool-v2.diff
Type: text/x-patch
Size: 10176 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20130106/07d05f0c/attachment.bin>
More information about the Gcc-patches
mailing list