[Patch, fortran] PR 40539 Document internal representation of LOGICAL variables

[Tobias Burnus]

On 04/06/2010 11:24 PM, Janne Blomqvist wrote:
> the attached documentation patch explains how gfortran represents
> LOGICAL variables. Ok for trunk/4.5/4.4?
>
> +In general, knowledge of the internal representation of @code{LOGICAL}
> +variables is not necessary, even for mixed language programming since
> +the introduction of the @code{ISO_C_BINDING} feature in Fortran 2003.
> +For those cases where knowledge of the internal representation is
> +after all required, the GNU Fortran internal representation is as
> +follows.
>   

I would delete this paragraph - it does not contain much information and
as experience shows (PR40539) using ISO_C_BINDING also does not
magically solve all problems. The standard also only talks about
"companion C processor", which is GCC's C compiler, but the issue (cf.
PR) was about implementation differences between two different (Fortran)
"processors" - ifort and gfortran.

> +A @code{LOGICAL(KIND=N)} variable is represented as an
> +@code{INTEGER(KIND=N)} variable, however with only two permissible
> +values: @code{1} for @code{.TRUE.} and @code{0} for
> +@code{.FALSE.}. Any other integer value results in undefined behavior.

Add a comma after the "however".

(For the mailing list readers: The problem is that ifort as optimization
checks the sign bit (thus: 0 and -1 for .false./.true.) while
GCC/gfortran uses the first bit on the other side (i.e. 0 and 1), which
leads to problems. As in C one usually uses integer expressions in
conditions, either choice is compatible with C [at least when not
explicitly using _Bool]. And somehow, ifort seems also to accept 1 as
.true. while gfortran regards -1 as .false. Thus, passing ifort's
.false. (and also .false._c_bool) to gfortran leads to wrong code. -
Disclaimer: I have not re-read the PR and might misremember.)

OK with the modifications. Note: GCC 4.5 is currently frozen - please
wait until unfrozen.

Tobias