From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <joseph_myers@mentor.com>
Received: from esa1.mentor.iphmx.com (esa1.mentor.iphmx.com [68.232.129.153])
 by sourceware.org (Postfix) with ESMTPS id 7354F3858283;
 Mon, 27 Jun 2022 20:54:38 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7354F3858283
Authentication-Results: sourceware.org; dmarc=none (p=none dis=none)
 header.from=codesourcery.com
Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com
X-IronPort-AV: E=Sophos;i="5.92,227,1650960000"; d="scan'208";a="80601084"
Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165])
 by esa1.mentor.iphmx.com with ESMTP; 27 Jun 2022 12:54:37 -0800
IronPort-SDR: FL4wWvQbMmVXND9SzCtqKQ6DJx6ruOevjqj5qxXH0MHyN51VL7fZltUfjWJ2Uvs2swYum2AaX6
 MSOUvUrlJ6E5A03U6Qr61osVwBPabQhaRRwfloNGrkFmcKLIoAuCdz4mq4WjkVo3Mo0+9/4WK7
 91twKcLeMMx4XCIRcdtlNAE2jO4ViKqmlwJ2CFDn/bbU8Nu0A4Bp7O5We76b72q8BptUiTEXpL
 TYoD6vAZ5Ldnuzf0Oajh2mVshDKYj+RShK8BFewarT8UIXUdl+QraFg7kptgTn5w3CBovd5rN2
 znE=
Date: Mon, 27 Jun 2022 20:54:32 +0000
From: Joseph Myers <joseph@codesourcery.com>
X-X-Sender: jsm28@digraph.polyomino.org.uk
To: Jakub Jelinek <jakub@redhat.com>
CC: Mikael Morin <morin-mikael@orange.fr>, <fortran@gcc.gnu.org>,
 <gcc-patches@gcc.gnu.org>, Harald Anlauf <anlauf@gmx.de>
Subject: Re: [PATCH] fortran, libgfortran, v2: Avoid using libquadmath for
 glibc 2.26+
In-Reply-To: <YrliJXK79C/R2TSo@tucnak>
Message-ID: <alpine.DEB.2.22.394.2206272049320.211537@digraph.polyomino.org.uk>
References: <YrRWw/7sfjW83px/@tucnak>
 <b5141887-84f8-ede1-c546-c6c86c32107e@gmx.de> <YrTYfo8/qRjh15Ci@tucnak>
 <YrWR/feBR28AlWlz@tucnak> <70657edb-4055-e183-7e09-5e1321beb7f5@orange.fr>
 <YrliJXK79C/R2TSo@tucnak>
User-Agent: Alpine 2.22 (DEB 394 2020-01-19)
MIME-Version: 1.0
X-Originating-IP: [137.202.0.90]
X-ClientProxiedBy: SVR-IES-MBX-07.mgc.mentorg.com (139.181.222.7) To
 svr-ies-mbx-10.mgc.mentorg.com (139.181.222.10)
X-Spam-Status: No, score=-3112.6 required=5.0 tests=BAYES_00,
 HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, KAM_SHORT, SPF_HELO_PASS,
 SPF_PASS, TXREP,
 T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
 server2.sourceware.org
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8BIT
X-Content-Filtered-By: Mailman/MimeDel 2.1.29
X-BeenThere: fortran@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Fortran mailing list <fortran.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/fortran>,
 <mailto:fortran-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/fortran/>
List-Help: <mailto:fortran-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/fortran>,
 <mailto:fortran-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Jun 2022 20:54:40 -0000

On Mon, 27 Jun 2022, Jakub Jelinek via Gcc-patches wrote:

> On Sun, Jun 26, 2022 at 08:45:28PM +0200, Mikael Morin wrote:
> > I don’t like the _Float128 vs __float128 business, it’s confusing.
> > And accordinog to https://gcc.gnu.org/onlinedocs/gcc/Floating-Types.html
> > they seem to be basically the same thing, so it’s also redundant.
> 
> I thought __float128 and _Float128 are distinct and incompatible in the FEs
> and equivalent in middle-end and back-end, but apparently they are
> considered equivalent even for _Generic.

Yes, when both are supported, they are the same type.  The main 
differences (not relevant for this patch, I think) are:

* _Float128 is supported on systems where long double has the IEEE 
binary128 format (as a distinct type from long double even when they have 
the same format); __float128 generally isn't supported on such systems.

* __float128 is supported in C++, _Float128 isn't (though we've discussed 
adding support for _FloatN type names and corresponding fN constant 
suffixes in C++; see the thread on the gcc list in March 2021).

-- 
Joseph S. Myers
joseph@codesourcery.com