This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch, fortran] PR 40539 Document internal representation of LOGICAL variables
- From: Tobias Burnus <burnus at net-b dot de>
- To: Janne Blomqvist <blomqvist dot janne at gmail dot com>
- Cc: Fortran List <fortran at gcc dot gnu dot org>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 07 Apr 2010 10:26:34 +0200
- Subject: Re: [Patch, fortran] PR 40539 Document internal representation of LOGICAL variables
- References: <t2p7b446c2e1004061424l4ff15edv4a92e02de7c229b9@mail.gmail.com>
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