From: Janne Blomqvist <blomqvist.janne@gmail.com>
To: Tobias Burnus <burnus@net-b.de>
Cc: gcc patches <gcc-patches@gcc.gnu.org>, gfortran <fortran@gcc.gnu.org>
Subject: Re: [Patch, Fortran] PR55758 - Non-C_Bool handling with BIND(C)
Date: Thu, 10 Jan 2013 19:42:00 -0000 [thread overview]
Message-ID: <CAO9iq9HM5CXDE4m29h84zphXq_sK01Jki7ruD9kc-2zmGtbNLQ@mail.gmail.com> (raw)
In-Reply-To: <50EC9EFF.8020706@net-b.de>
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
next prev parent reply other threads:[~2013-01-10 19:42 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-27 22:31 Tobias Burnus
2012-12-29 22:11 ` Janne Blomqvist
2012-12-30 10:42 ` Tobias Burnus
2013-01-06 16:52 ` Tobias Burnus
2013-01-06 18:31 ` Steve Kargl
2013-01-08 20:07 ` Janne Blomqvist
2013-01-08 22:34 ` Tobias Burnus
2013-01-10 19:42 ` Janne Blomqvist [this message]
2013-02-26 14:58 ` Tobias Burnus
2013-01-09 16:22 ` Tobias Burnus
2013-01-09 17:23 ` Mikael Morin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAO9iq9HM5CXDE4m29h84zphXq_sK01Jki7ruD9kc-2zmGtbNLQ@mail.gmail.com \
--to=blomqvist.janne@gmail.com \
--cc=burnus@net-b.de \
--cc=fortran@gcc.gnu.org \
--cc=gcc-patches@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).