From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24049 invoked by alias); 10 Apr 2013 07:38:31 -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 24033 invoked by uid 89); 10 Apr 2013 07:38:31 -0000 X-Spam-SWARE-Status: No, score=-5.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE autolearn=ham version=3.3.1 Received: from mail-we0-f174.google.com (HELO mail-we0-f174.google.com) (74.125.82.174) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Wed, 10 Apr 2013 07:38:29 +0000 Received: by mail-we0-f174.google.com with SMTP id u12so123726wey.19 for ; Wed, 10 Apr 2013 00:38:27 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.178.100 with SMTP id cx4mr1293778wjc.47.1365579507712; Wed, 10 Apr 2013 00:38:27 -0700 (PDT) Received: by 10.194.56.100 with HTTP; Wed, 10 Apr 2013 00:38:27 -0700 (PDT) In-Reply-To: References: <506C72C7.7090207@naturalbridge.com> <87pq3y3kyk.fsf@sandifor-thinkpad.stglab.manchester.uk.ibm.com> <50912D85.1070002@naturalbridge.com> <5091331C.3030504@naturalbridge.com> <512D686B.90000@naturalbridge.com> <515B16EB.5020303@naturalbridge.com> <515C1AFB.3080105@naturalbridge.com> <515C55D7.7020003@naturalbridge.com> <5161AA07.7090706@naturalbridge.com> <5162BB64.3070007@naturalbridge.com> Date: Wed, 10 Apr 2013 09:44:00 -0000 Message-ID: Subject: Re: Comments on the suggestion to use infinite precision math for wide int. From: Richard Biener To: Lawrence Crowl Cc: Ian Lance Taylor , Richard Sandiford , Mike Stump , Kenneth Zadeck , gcc-patches Content-Type: text/plain; charset=ISO-8859-1 X-SW-Source: 2013-04/txt/msg00577.txt.bz2 On Tue, Apr 9, 2013 at 5:36 PM, Lawrence Crowl wrote: > > On Apr 9, 2013 2:02 AM, "Richard Biener" wrote: >> >> On Mon, Apr 8, 2013 at 10:39 PM, Lawrence Crowl wrote: >> > On 4/8/13, Kenneth Zadeck wrote: >> >> The other problem, which i invite you to use the full power of >> >> your c++ sorcery on, is the one where defining an operator so >> >> that wide-int + unsigned hwi is either rejected or properly >> >> zero extended. If you can do this, I will go along with >> >> your suggestion that the internal rep should be sign extended. >> >> Saying that constants are always sign extended seems ok, but there >> >> are a huge number of places where we convert unsigned hwis as >> >> the second operand and i do not want that to be a trap. I went >> >> thru a round of this, where i did not post the patch because i >> >> could not make this work. And the number of places where you >> >> want to use an hwi as the second operand dwarfs the number of >> >> places where you want to use a small integer constant. >> > >> > You can use overloading, as in the following, which actually ignores >> > handling the sign in the representation. >> > >> > class number { >> > unsigned int rep1; >> > int representation; >> > public: >> > number(int arg) : representation(arg) {} >> > number(unsigned int arg) : representation(arg) {} >> > friend number operator+(number, int); >> > friend number operator+(number, unsigned int); >> > friend number operator+(int, number); >> > friend number operator+(unsigned int, number); >> > }; >> > >> > number operator+(number n, int si) { >> > return n.representation + si; >> > } >> > >> > number operator+(number n, unsigned int ui) { >> > return n.representation + ui; >> > } >> > >> > number operator+(int si, number n) { >> > return n.representation + si; >> > } >> > >> > number operator+(unsigned int ui, number n) { >> > return n.representation + ui; >> > } >> >> That does not work for types larger than int/unsigned int as HOST_WIDE_INT >> usually is (it's long / unsigned long). When you pass an int or unsigned >> int >> to >> >> number operator+(unsigned long ui, number n); >> number operator+(long ui, number n) >> >> you get an ambiguity. You can "fix" that by relying on template argument >> deduction and specialization instead of on overloading and integer >> conversion >> rules. > > Ah, I hadn't quite gotten the point. This problem is being fixed in the > standard, but that won't help GCC anytime soon. > >> >> > If the argument type is of a template type parameter, then >> > you can test the template type via >> > >> > if (std::is_signed::value) >> > .... // sign extend >> > else >> > .... // zero extend >> > >> > See http://www.cplusplus.com/reference/type_traits/is_signed/. >> >> Yes, if we want to use the standard library. For what integer types >> is std::is_signed required to be implemented in C++98 (long long?)? > > It is in C++03/TR1, which is our base requirement. Otherwise, we can test > ~(T)0<(T)0. Yeah, I think we want to test ~(T)0<(T)0 here. Relying on C++03/TR1 is too obscure if there is an easy workaround. Richard. >> Consider non-GCC host compilers. >> >> Richard. >> >> > If you want to handle non-builtin types that are asigne dor unsigned, >> > then you need to add a specialization for is_signed. >> > >> > -- >> > Lawrence Crowl