From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 559C9385AE7D for ; Mon, 27 Jun 2022 07:54:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 559C9385AE7D Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-141-E27cbe6kMOyYTnDZpH2_mA-1; Mon, 27 Jun 2022 03:54:29 -0400 X-MC-Unique: E27cbe6kMOyYTnDZpH2_mA-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.rdu2.redhat.com [10.11.54.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 00D25801233; Mon, 27 Jun 2022 07:54:29 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.30]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 79DD41410DD8; Mon, 27 Jun 2022 07:54:28 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 25R7sF1p1829172 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 27 Jun 2022 09:54:15 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 25R7sDFL1829171; Mon, 27 Jun 2022 09:54:13 +0200 Date: Mon, 27 Jun 2022 09:54:13 +0200 From: Jakub Jelinek To: Mikael Morin Cc: Harald Anlauf , gcc-patches@gcc.gnu.org, "Joseph S. Myers" , fortran@gcc.gnu.org Subject: Re: [PATCH] fortran, libgfortran, v2: Avoid using libquadmath for glibc 2.26+ Message-ID: Reply-To: Jakub Jelinek References: <70657edb-4055-e183-7e09-5e1321beb7f5@orange.fr> MIME-Version: 1.0 In-Reply-To: <70657edb-4055-e183-7e09-5e1321beb7f5@orange.fr> X-Scanned-By: MIMEDefang 2.85 on 10.11.54.7 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham 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 List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2022 07:54:32 -0000 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. Still, using __float128 when the APIs are declared for __float128 and _Float128 when the APIs are declared for _Float128 can be better for consistency. But if you feel strongly that we should use _Float128 and F128/f128 suffixes on floating point constants everywhere, we'd need more work (e.g. because we use those same suffixes also for the functions where we need to differentiate, or on macros like M_PI etc. where it is significant too), and we'd need to come up with new macros to differentiate which API set to use. In the patch I've posted, HAVE_FLOAT128 and GFC_REAL_16_IS_FLOAT128 defines stand for __float128 + libquadmath APIs, HAVE__FLOAT128 and GFC_REAL_16_IS__FLOAT128 stand for _Float128 and C *f128 APIs. 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. And the hardest part would be that we that GFC_REAL_{16,17}_LITERAL{,_SUFFIX} is currently used everywhere while for library APIs and M_* constants we need to differentiate. Perhaps we could just use *q suffixes even when using _Float128 when USE_LIBQUADMATH. Jakub