From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 90540 invoked by alias); 25 Nov 2019 20:34:12 -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 90532 invoked by uid 89); 25 Nov 2019 20:34:12 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-9.6 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2 autolearn=ham version=3.3.1 spammy=lived X-HELO: smtp.CeBiTec.Uni-Bielefeld.DE Received: from smtp.CeBiTec.Uni-Bielefeld.DE (HELO smtp.CeBiTec.Uni-Bielefeld.DE) (129.70.160.84) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 25 Nov 2019 20:34:11 +0000 Received: from localhost (localhost.CeBiTec.Uni-Bielefeld.DE [127.0.0.1]) by smtp.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTP id 37EAF6B6; Mon, 25 Nov 2019 21:34:09 +0100 (CET) Received: from smtp.CeBiTec.Uni-Bielefeld.DE ([127.0.0.1]) by localhost (malfoy.CeBiTec.Uni-Bielefeld.DE [127.0.0.1]) (amavisd-new, port 10024) with LMTP id BNUBQUkkgYdY; Mon, 25 Nov 2019 21:34:04 +0100 (CET) Received: from manam.CeBiTec.Uni-Bielefeld.DE (p5085478D.dip0.t-ipconnect.de [80.133.71.141]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.CeBiTec.Uni-Bielefeld.DE (Postfix) with ESMTPSA id E1BFF6B5; Mon, 25 Nov 2019 21:34:03 +0100 (CET) From: Rainer Orth To: Joseph Myers Cc: , Jonathan Wakely Subject: Re: Prevent all uses of DFP when unsupported (PR c/91985) References: Date: Mon, 25 Nov 2019 20:36:00 -0000 In-Reply-To: (Joseph Myers's message of "Fri, 22 Nov 2019 16:40:01 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2019-11/txt/msg02347.txt.bz2 Hi Joseph, > Code that directly uses _Decimal* types on architectures not > supporting DFP is properly diagnosed ("error: decimal floating-point > not supported for this target"), via a call to > targetm.decimal_float_supported_p, if the _Decimal32, _Decimal64 or > _Decimal128 keywords are used to access it. Use via mode attributes > is also diagnosed ("unable to emulate 'SD'"); so is use of the > FLOAT_CONST_DECIMAL64 pragma. However, it is possible to access those > types via typeof applied to constants or built-in functions without > such an error. I expect that there are ways to get an ICE from this; > certainly it uses a completely undefined ABI. > > This patch arranges for the types not to exist in the compiler at all > when DFP is not supported. As is done with unsupported _FloatN / > _FloatNx types, the global tree nodes are left as NULL_TREE, and the > built-in function machinery is made to use error_mark_node for them in > that case in builtin-types.def, so that the built-in functions are > unavailable. Code handling constants is adjusted to give an error, > and other code that might not work with the global tree nodes being > NULL_TREE is also updated. > > Bootstrapped with no regressions for x86_64-pc-linux-gnu. Also tested > with no regressions for cross to aarch64-linux-gnu, as a configuration > without DFP support. OK to commit (the changes that aren't C front-end > changes)? AFAICS this caused +FAIL: libstdc++-abi/abi_check on Solaris. In libstdc++.log I find # of added symbols: 0 # of missing symbols: 9 # of undesignated symbols: 0 # of incompatible symbols: 9 9 missing symbols 0 _ZTIDf typeinfo for decimal32 version status: unversioned type: object type size: 8 status: subtracted [...] 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. Rainer -- ----------------------------------------------------------------------------- Rainer Orth, Center for Biotechnology, Bielefeld University