From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6245 invoked by alias); 8 Apr 2013 23:46:40 -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 6234 invoked by uid 89); 8 Apr 2013 23:46:40 -0000 X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE autolearn=ham version=3.3.1 Received: from mail-vb0-f48.google.com (HELO mail-vb0-f48.google.com) (209.85.212.48) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Mon, 08 Apr 2013 23:46:39 +0000 Received: by mail-vb0-f48.google.com with SMTP id p13so4239561vbe.35 for ; Mon, 08 Apr 2013 16:46:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=v4dBRDz6o+nRD5KK449S961ow163g0gJ8RNWM57GdZQ=; b=AGQtTHR3gPfMib4VE4YQAlARgy9YZxlIeL2JnudrEbgRJvu0JicbI5XnrHgUVRRUhT irzOWottJt4xrS1UrMqNxoNxUL9XXwCl9yOO6+1EP79mm+tP6Ba8CqieHqumltGx0BKx +XI+trYT10qGQKzLjgoaRnWJUsL1XquLgqB6/wYOFzCnYQUcoO3It+emYQrQ6UAr0w/v lUjJGph0PgssT+n8LTABl9YCDWHLDsF0MEkAVw6kRNVPKmMEt9Ggp+M4F9R0C7hzcnQd JspACVxbKwt6ASyoDpnG0MKx7IIQmGLmWvd7TBjVx3E/gd0PMmpUgEnzAHHL6oYpr1C3 M/2w== X-Received: by 10.58.220.229 with SMTP id pz5mr17537786vec.30.1365464797582; Mon, 08 Apr 2013 16:46:37 -0700 (PDT) Received: from [192.168.1.10] (pool-108-46-172-132.nycmny.fios.verizon.net. [108.46.172.132]) by mx.google.com with ESMTPS id d13sm27473733vdj.8.2013.04.08.16.46.36 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 08 Apr 2013 16:46:36 -0700 (PDT) Message-ID: <516356DB.6090800@naturalbridge.com> Date: Tue, 09 Apr 2013 08:22:00 -0000 From: Kenneth Zadeck User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130308 Thunderbird/17.0.4 MIME-Version: 1.0 To: Robert Dewar CC: Mike Stump , Lawrence Crowl , Florian Weimer , Richard Biener , gcc-patches , rdsandiford@googlemail.com, Ian Lance Taylor Subject: Re: Comments on the suggestion to use infinite precision math for wide int. References: <506C72C7.7090207@naturalbridge.com> <515B16EB.5020303@naturalbridge.com> <515C1AFB.3080105@naturalbridge.com> <515C55D7.7020003@naturalbridge.com> <5161AA07.7090706@naturalbridge.com> <51628648.3030606@redhat.com> <5162C2EB.4070601@naturalbridge.com> <5162C3CF.9090506@adacore.com> <5162C4CD.1030404@naturalbridge.com> <5162CB9B.6070309@adacore.com> <5162D04F.7020907@adacore.com> <5162D37F.40403@naturalbridge.com> <5162D59E.4010700@adacore.com> <51633878.9090206@adacore.com> <51633AAA.5040404@naturalbridge.com> <51633B4B.301 0601@adacore.com> <57DE9BD7-4521-4053-9DFE-C4EFB8E2B443@comcast.net> <516348A3.70000@adacore.com> In-Reply-To: <516348A3.70000@adacore.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQl90inwNKIBSESmKvr3fqrKCDl2H4nin3n6rxIA96biseelpIr94NB/PZSeLg2ziHi98Ipn X-SW-Source: 2013-04/txt/msg00497.txt.bz2 On 04/08/2013 06:45 PM, Robert Dewar wrote: > On 4/8/2013 6:34 PM, Mike Stump wrote: >> On Apr 8, 2013, at 2:48 PM, Robert Dewar wrote: >>> That may be so in C, in Ada it would be perfectly reasonable to use >>> infinite precision for intermediate results in some cases, since the >>> language standard specifically encourages this approach. >> >> gcc lacks an infinite precision plus operator?! :-) >> > Right, that's why we do everything in the front end in the > case of Ada. But it would be perfectly reasonable for the > back end to do this substitution. but there is no way in the current tree language to convey which ones you can and which ones you cannot.