From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7910 invoked by alias); 26 Nov 2019 12:14:00 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 7902 invoked by uid 89); 26 Nov 2019 12:14:00 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.7 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.1 spammy=H*Ad:U*ro, useless X-HELO: us-smtp-delivery-1.mimecast.com Received: from us-smtp-2.mimecast.com (HELO us-smtp-delivery-1.mimecast.com) (205.139.110.61) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 26 Nov 2019 12:13:59 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1574770437; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=eJ0mH5syLSXV0rCDrXJcsdlVTwZphJHyKJ1ktf4PZVY=; b=Ad0oLkxxSZKnB2NtEA2XId6xRMKufBovSBd/pQ7BgfrAqA+gr0Etnyo7HmvnrLivQsY8Ba k+L5h4K31bKOeEKg5p225rXrAL3U/kRkm2qXMAQLTSvjIZ/mDyxp30sL1ng+D8Wlu5Ay7/ DCj4H2qPP7YhUWorYYSC8EQZA3Bj5ZA= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-212-kPM1XvKsPGe3LiKe7DUliA-1; Tue, 26 Nov 2019 07:13:52 -0500 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 27707102CE19; Tue, 26 Nov 2019 12:13:51 +0000 (UTC) Received: from localhost (unknown [10.33.36.157]) by smtp.corp.redhat.com (Postfix) with ESMTP id 64A486B8CD; Tue, 26 Nov 2019 12:13:50 +0000 (UTC) Date: Tue, 26 Nov 2019 12:21:00 -0000 From: Jonathan Wakely To: Joseph Myers Cc: Rainer Orth , gcc-patches@gcc.gnu.org Subject: Re: Prevent all uses of DFP when unsupported (PR c/91985) Message-ID: <20191126121349.GK11522@redhat.com> References: MIME-Version: 1.0 In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett User-Agent: Mutt/1.12.1 (2019-06-15) X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-SW-Source: 2019-11/txt/msg02398.txt.bz2 On 26/11/19 00:57 +0000, Joseph Myers wrote: >On Mon, 25 Nov 2019, Rainer Orth wrote: > >> and a few more, all DFP related. They used to be emitted by g++ for >> __fundamental_type_info in libsupc++/fundamental_type_info.cc and lived >> in the CXXABI_1.3.4 version. However, since Solaris *does* lack DFP >> support, that's no longer the case. I'm uncertain how best to deal with >> this, however. > >As I understand it, _GLIBCXX_USE_DECIMAL_FLOAT should already have been >undefined for this target, and so std::decimal::decimal32 etc. should not >have been usable (both the header not working without that define, and the >mode attributes in the header being rejected by the front end when DFP is >unsupported). I.e. such defines in libsupc++ would never have been usable >on this target, so I think they are something it should be safe to remove >from the ABI baseline. If it's actually impossible that any real program could have depended on those symbols, then I agree. We could consider adding some useless stubs with those symbol names (as aliases of something else?) so the symbols are still in the library, to keep various tools happy.