From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <morin-mikael@orange.fr>
Received: from smtp.smtpout.orange.fr (smtp06.smtpout.orange.fr
 [80.12.242.128])
 by sourceware.org (Postfix) with ESMTPS id 3DB96386F0EB
 for <fortran@gcc.gnu.org>; Mon, 27 Jun 2022 11:56:19 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3DB96386F0EB
Authentication-Results: sourceware.org;
 dmarc=none (p=none dis=none) header.from=orange.fr
Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=orange.fr
Received: from [192.168.1.17] ([86.215.161.154]) by smtp.orange.fr with ESMTPA
 id 5nLeoEzcfP8Ap5nLkouhEF; Mon, 27 Jun 2022 13:56:17 +0200
X-ME-Helo: [192.168.1.17]
X-ME-Auth: MDU4MTIxYWM4YWI0ZGE4ZTUwZWZmNTExZmI2ZWZlMThkM2ZhYiE5OWRkOGM=
X-ME-Date: Mon, 27 Jun 2022 13:56:17 +0200
X-ME-IP: 86.215.161.154
Message-ID: <38312dfa-76c6-ee85-9f6a-80c6e2f7bcdb@orange.fr>
Date: Mon, 27 Jun 2022 13:56:10 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.10.0
Subject: Re: [PATCH] fortran, libgfortran, v2: Avoid using libquadmath for
 glibc 2.26+
Content-Language: en-US
To: Jakub Jelinek <jakub@redhat.com>
Cc: Harald Anlauf <anlauf@gmx.de>, gcc-patches@gcc.gnu.org,
 "Joseph S. Myers" <joseph@codesourcery.com>, fortran@gcc.gnu.org
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>
From: Mikael Morin <morin-mikael@orange.fr>
In-Reply-To: <YrliJXK79C/R2TSo@tucnak>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00, FREEMAIL_FROM,
 JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_DNSWL_NONE,
 RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, 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
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 11:56:20 -0000

Le 27/06/2022 à 09:54, Jakub Jelinek a écrit :
> Still, using __float128 when the APIs are declared for __float128 and
> _Float128 when the APIs are declared for _Float128 can be better for
> consistency.
> 
I agree with that.
I was implicitly suggesting to change the libquadmath API to use the 
standard syntax and types, with the assumption that it’s an internal 
thing used only by fortran (on the frontend side and on the library 
side). After documenting myself further, it seems that’s a wrong 
assumption.


> If HAVE_FLOAT128 and GFC_REAL_16_IS_FLOAT128 stand for
> _Float128 and libquadmath or *f128 APIs, we'd need some macro
> to tell which APIs to use, say
> USE_LIBQUADMATH and USE_IEC_60559.

That would be my preference, even if we keep both __float128 and 
_Float128, as it avoids exposing the detail of the provider of the math 
functions in many places it’s not needed.
Half of the changes from your patch have pattern blah__float128 || 
blah_Float128 or the negation of that, and wouldn’t be needed if the 
*FLOAT128 conditions spanned both __float128 and _Float128 (or 
libquadmath and libc).