This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug fortran/40539] Inversion of logical function compiled with ifort not correct.
- From: "burnus at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 24 Jun 2009 17:59:35 -0000
- Subject: [Bug fortran/40539] Inversion of logical function compiled with ifort not correct.
- References: <bug-40539-17875@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #8 from burnus at gcc dot gnu dot org 2009-06-24 17:59 -------
Alexander, I just filled Issue 553679 at premier.intel.com as associated bug. I
realized that the issue is even bigger:
C99's 6.3.1.2 has "When any scalar value is converted to _Bool, the result is 0
if the value compares equal to 0; otherwise, the result is 1." Thus with
BIND(C) and using LOGICAL(C_BOOL), the C compiler (or a Fortran compiler with C
binding) can expect that .TRUE. matches "1" and can do optimizations based on
this assumption.
(In reply to comment #5)
> The real problem with the issue is that code compiled with GFORTRAN could have
> issues if linked with a vendor library. I'm experiencing ones with Intel
> MKL.
>
> It would be nice to have an option to turn off that fast inversion, at least
> for compatibility. Or at least to make -O0 case compatible.
First, I think we agree that this is not only a gfortran <-> ifort but a GCC
(gcc,g++,gfortran) <-> ifort interoperability problem.
Secondly, using GCC, one can work around the problem using
! ((int) lsame())
and
transfer(lsame(),0) == 0
which is quite ugly.
Thirdly, one can think of an option in GCC (or only gfortran), but I think
changing the behaviour for -O0 is not a good solution: Telling someone to use
-O0 with MKL is not helpful and it hampers finding out what goes wrong. One
thus needs to have an option which applies at all optimization levels.
Fourthly, one can think about modifing ifort and how to build the MKL.
(Unfortunately, I do not see a good solution for this - all are not really
userfriendly.)
In summary: This is a quite special but rather ugly interoperability problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40539