On 3/24/2014 2:56 PM, Ondřej Čertík wrote:
> Hi,
>
> The Fortran 2003 standard says that logical(c_bool) in Fortran and
> "bool" in C should be interoperable. Unfortunately, this only works in
> gfortran. Both Intel and PGI fail. Here is a minimal example:
>
> https://gist.github.com/certik/9744747
>
> PGI and Intel behave the same, and both fail. The reason is that Intel
> represents .true. as -1, but when you pass true from C, it is
> represented as 1. In Fortran, .not. causes 1 (= .true. in Intel
> Fortran) to become -2 (still .false. in Intel Fortran), but when you
> return to C, -2 is interpreted as true. I was using ifort and icc for
> this example.
>
> Here are some relevant links if you want to learn more about this:
>
> http://gcc.gnu.org/onlinedocs/gfortran/Intrinsic-Types.html
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40539
> http://software.intel.com/en-us/blogs/2012/05/11/doctor-fortran-in-i-can-c-clearly-now-part-i
>
> Intel has an option to fix this, it's enough to use -fpscomp logical,
> though it might slow things down.
>
> Isn't this a bug in Intel? Because clearly, the logical(c_bool) and
> bool are *not* interoperable in ifort (with default options), as my
> example shows, using Intel's own Fortran and C compilers. I'll be
> happy to report this as a bug, but I wanted to check with you first,
> whether you agree that this is a bug.
>
> Ondrej
As the reference you cited points out options required for standards
compatibility in ifort, it's clear that Intel has studied this
question. One might argue that some of these should default to standard
rather than backwards compatibility with predecessor compilers.
I believe the default representation of .true. is tied in with the
default of accepting logical operators on integer values (and the
extended logical operators), so it's difficult to guess how many
non-compliant applications would be impacted by a change in default.
--
Tim Prince
|