On Mon, Mar 24, 2014 at 2:05 PM, Ondřej Čertík <[log in to unmask]> wrote:
> Hi Bill,
>
> On Mon, Mar 24, 2014 at 1:50 PM, Bill Long <[log in to unmask]> wrote:
>>
>> On Mar 24, 2014, at 2:21 PM, Ondřej Čertík <[log in to unmask]> wrote:
>>
>>> On Mon, Mar 24, 2014 at 1:05 PM, Bill Long <[log in to unmask]> wrote:
>>>>
>>>> If there is no Fortran LOGICAL representation that matches the corresponding c _Bool then the value of c_bool in the iso_c_binding module should be -1. If that is what you find, then the compiler is behaving correctly.
>>>
>>> The value of c_bool on Intel on my machine is "1", however, the type
>>> is not interoperable, unless you specify -fpscomp logical. Btw, Cray
>>> seems to have the same issue, see the results from a colleague who has
>>> access to Cray: https://gist.github.com/jeffhammond/9746080
>>
>> I’m not sure what Jeff is doing. I tried the example codes in the github link with the Cray compiler and get:
>>
>>> ftn -c modu.f90
>>> cc main.c modu.o
>>> ./a.out
>> 3, T, F
>> true -> false
>> 3, F, T
>> false -> true
>> Done.
>>
>> Additionally, I tried a simpler code:
>>
>> use,intrinsic :: iso_c_binding
>> logical(c_bool) :: x
>> x = .true.
>> print *, c_bool
>> write (*,"(g10.8,L5)") transfer (x, 0_1), x
>> x = .not. x
>> write (*,"(g10.8,L5)") transfer (x, 0_1), x
>>
>> end
>>
>> which results in
>>
>>> ftn test.f90
>>> ./a.out
>> 1
>> 1 T
>> 0 F
>>
>> illustrating that the Cray compiler does use 1 and 0 for true and false, so does have correct interoperability.
>
> Thanks a lot for that! I CCed Jeff about this.
>
> It's good to know that Cray is standard compliant about this. So is
> gfortran. Intel is fixed by the -standard-semantics option. Now I just
> need to figure out how to fix PGI and all is good.
For PGI, the option -Munixlogical fixes it.
Ondrej
>
> Ondrej
|