From owner-sc22wg5+sc22wg5-dom9=www.open-std.org@open-std.org Wed Dec 11 12:50:32 2024 Return-Path: X-Original-To: sc22wg5-dom9 Delivered-To: sc22wg5-dom9@www.open-std.org Received: by www.open-std.org (Postfix, from userid 521) id E60FC357068; Wed, 11 Dec 2024 12:50:32 +0100 (CET) Delivered-To: sc22wg5@open-std.org Received: from mail-pg1-f171.google.com (mail-pg1-f171.google.com [209.85.215.171]) by www.open-std.org (Postfix) with ESMTP id 73723356B5B for ; Wed, 11 Dec 2024 12:50:32 +0100 (CET) Received: by mail-pg1-f171.google.com with SMTP id 41be03b00d2f7-7fd17f231a7so4434161a12.0 for ; Wed, 11 Dec 2024 03:50:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=stevelionel.com; s=google; t=1733917830; x=1734522630; darn=open-std.org; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=AsPdtZdOY3QW2lwyqFaZ05PsPRpzF3yT3jOUcfcKNaU=; b=PgKrSesv0EW95KKFAIQbkx4BTQkcmKElwS8kuXLZ95DDsEgxf6tPnXqDzX8PKrXFRQ kZQ/T2h3mRSz0VhSSYcdEYmIXwRGQy/+GUmMww9MMEX7U01DBRnc891kBL0DphE06lVH 5dG3M3ICZFSYLZMuxtsDKkrQ7v+jqsrhlB1mk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733917830; x=1734522630; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=AsPdtZdOY3QW2lwyqFaZ05PsPRpzF3yT3jOUcfcKNaU=; b=nsYgp9RcnAJ9278DJYWjkkN0qxIhPxWUANrsISpFf0KKO16aKuZuaOEYorGjtnxzCl TYc6a6wUvB9FC5PVnNzA5Q1vwXvtPTRZlLvPVcpjhBZToGr1Dpm8XZjbDDQ8Bj4w2nHk Msn7w3nc1VeAe5CT3aU/x2NXMGvtHKN/aDqL+RJBqJ1jtSLOFChM9MPjkzCEnDkgSq6g YEvdTO334GXEoTtCVKn1CtM5SrB+COCbpogcaA6rkp7Nog6Kr/dwSHW5SpVqRego+gTk bVH8baYZuw2JYi/VMK8/qjrykecXrfETe7MfSteYr8Ko3pzdDct1yJVuCg6S+yiA4Yct A3PA== X-Gm-Message-State: AOJu0YzbGUod/ON7l011dyzsv1NWkhsXdoZne7qtcz8PmUeCP2q0FPDb ILd8Z8tZTHoUq+Cuh4XORyha27GJHAglSI6GAQRngP3BAOuBlHwqFnSgfCQAGpOq1u8YAaRSSm6 76M6bk86/5CPKzrbYDbqwIBEsCzzeqtFxNiRjwElRVk0qCyam X-Gm-Gg: ASbGncu7MMC9+yMDRUJyBUCk9g8l5uahR54Fespva4EYe2umxJShU4XuIUWePThtsc4 uy8FWJb+bDwxp7UFsE5k/KDkFBQfSndR7Xdc= X-Google-Smtp-Source: AGHT+IHWEpBpM6ZRb8KHNCGQHSrgOt3GxUL8ETneqo9m/xPqvQv851JWzuUVzimyWHUsmcbVOq5axN41BMzToQRQcwI= X-Received: by 2002:a17:90b:28cf:b0:2ee:693e:ed7a with SMTP id 98e67ed59e1d1-2f12804a858mr3939352a91.35.1733917830361; Wed, 11 Dec 2024 03:50:30 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Steve Lionel Date: Wed, 11 Dec 2024 06:50:19 -0500 Message-ID: Subject: Re: [J3] [SC22WG5.6657] Question on the implementation of LOGICAL To: WG5 Content-Type: multipart/alternative; boundary="0000000000005951b70628fd34e0" Sender: owner-sc22wg5@open-std.org Precedence: bulk --0000000000005951b70628fd34e0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I covered this in https://stevelionel.com/drfortran/2000/04/29/doctor-fortran-in-to-eqv-or-to= -neqv-that-is-the-question-or-its-only-logical/ VAX used a low-bit test, not sign bit. Intel Fortran defaults to that, but if you use -standard-semantics it switches to the C style in support of C interop. As I say in the blog post, you can=E2=80=99t detect what method th= e compiler uses in a standard-conforming way (I don=E2=80=99t count using TRA= NSFER.) I have never heard of an implementation that cares what the value is other than whether it passes its test for true or false. On Wed, Dec 11, 2024 at 4:51=E2=80=AFAM Jeff Hammond via J3 < j3@mailman.j3-fortran.org> wrote: > For MPI reasons, I looked at the literals used by various Fortran > compilers for Booleans. > > > > Obviously, Fortran doesn=E2=80=99t specify these, and I have heard the si= gned bit > was used for Booleans on the VAX. Today, the only values I see are 0 and= 1 > or -1, both of which are compatible with C, at least in one direction. > > > > What I wonder is whether any implementation ever checks to see if a > LOGICAL value is strictly .TRUE. or .FALSE., i.e., detects alternative > values of .TRUE.. I assume that, for efficiency, compilers generate code > equivalent to C and only looks for .TRUE. via a non-zero. > --0000000000005951b70628fd34e0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I covered this in=C2=A0

VAX used a low-b= it test, not sign bit. Intel Fortran defaults to that, but if you use -stan= dard-semantics it switches to the C style in support of C interop. As I say= in the blog post, you can=E2=80=99t detect what method the compiler uses i= n a standard-conforming way (I don=E2=80=99t count using TRANSFER.)

I have never heard of an implem= entation that cares what the value is other than whether it passes its test= for true or false.

On Wed, Dec 11, 2024 at 4:51=E2=80=AFAM Jeff = Hammond via J3 <j3@mailman.= j3-fortran.org> wrote:

For MPI reasons, I looked at the literals used by va= rious Fortran compilers for Booleans.

=C2=A0

Obviously, Fortran doesn=E2=80=99t specify these, an= d I have heard the signed bit was used for Booleans on the VAX.=C2=A0 Today= , the only values I see are 0 and 1 or -1, both of which are compatible wit= h C, at least in one direction.

=C2=A0

What I wonder is whether any implementa= tion ever checks to see if a LOGICAL value is strictly .TRUE. or .FALSE., i= .e., detects alternative values of .TRUE..=C2=A0 I assume that, for efficie= ncy, compilers generate code equivalent to C and only looks for .TRUE. via a non-zero.

--0000000000005951b70628fd34e0--