------- Comment #10 from jb at gcc dot gnu dot org 2010-04-04 10:56 ------- I've been thinking a bit about this issue. Some observations
- There are a lot of compilers, and many ways of representing logicals. Being compatible with some or all of them is, IMO, a stillborn idea. And even if we'd solve the logical issue, there are other more or less subtle issues as well. To the extent that robust interoperability is desired, the solution is to use ISO_C_BINDING. - OTOH, there is a good case to be made for being compatible with C99 _Bool. That means we can handle LOGICAL and LOGICAL(C_BOOL) identically, we can use the middle-end logical type as-is etc. However, I believe we have already accomplished this. As Tobias already noted, as the compiler can assume that the value is either 0 or 1, it can optimize based on that, and it seems this is the cause of this problem with MKL. As Fortran, contrary to C, does not allow integers to be used as logical values, in principle we never need to worry about the case where the integer value of a logical variable is neither 0 nor 1. - Doing logical comparison C-style where /= 0 is equivalent to true might be used for non-standard code playing tricks with transfer or equivalence, or for C code calling Fortran passing an integer for a logical argument (essentially the same as equivalencing integer and logical). Is this case important enough to worry about? I doubt it, but OTOH I don't think the performance difference is measurable anyways. At least on x86, a bit test instruction is no less expensive (see http://www.agner.org/optimize/instruction_tables.pdf ) than a normal comparison, and in fact http://www.agner.org/optimize/optimizing_assembly.pdf recommends to avoid the bit test instructions and instead using XOR, TEST etc. The only place where I believe there is a difference is the negation (.NOT.). If we assume the value is either 0 or 1, a xor instruction (1 cycle on current processors) is enough. If, OTOH, we do the /= 0 test, we need a TEST or CMP instruction (1 cycle) followed by a SET (1 cycle). So we lose 1 cycle; I have a hard time imagining a real application where this makes any difference. In conclusion, IMHO, if gfortran current behavior is compatible with C99 _Bool, and thus LOGICAL and LOGICAL(C_BOOL) are equivalent, this PR should be closed as WONTFIX. If not, we should fix gfortran to follow C99 behavior. In either case, there should be some documentation specifying the internal representation of LOGICALs -- jb at gcc dot gnu dot org changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jb at gcc dot gnu dot org Last reconfirmed|0000-00-00 00:00:00 |2010-04-04 10:56:20 date| | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40539
