This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: [Patch, Fortran] PR55758 - Non-C_Bool handling with BIND(C)
On Wed, Jan 9, 2013 at 12:34 AM, Tobias Burnus <burnus@net-b.de> wrote:
> Janne Blomqvist worte:
>>
>> On Sun, Jan 6, 2013 at 6:52 PM, Tobias Burnus<burnus@net-b.de> 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.
Ah, thanks for the clarification. I think if we cannot make it really
bullet-proof, then it's safer to reject it outright.
Do you happen to know if anyone except openmpi would be affected? If
only openmpi, then we could give them a nudge and the issue would
likely be fixed by the time gcc 4.8 rolls out to end users.
--
Janne Blomqvist