From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5837 invoked by alias); 6 Nov 2002 21:11:02 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 5825 invoked from network); 6 Nov 2002 21:11:00 -0000 Received: from unknown (HELO atrey.karlin.mff.cuni.cz) (195.113.31.123) by sources.redhat.com with SMTP; 6 Nov 2002 21:11:00 -0000 Received: by atrey.karlin.mff.cuni.cz (Postfix, from userid 4018) id BAE814F9B2; Wed, 6 Nov 2002 22:10:59 +0100 (CET) Date: Wed, 06 Nov 2002 13:11:00 -0000 From: Jan Hubicka To: Richard Henderson , Jan Hubicka , gcc-patches@gcc.gnu.org, aj@suse.de Subject: Re: Simplify floating point conversions II Message-ID: <20021106211059.GB1316@atrey.karlin.mff.cuni.cz> References: <20021105171400.GX14655@kam.mff.cuni.cz> <20021105173800.GD20534@redhat.com> <20021106092310.GE22059@kam.mff.cuni.cz> <20021106175441.GZ22059@kam.mff.cuni.cz> <20021106180930.GA22066@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20021106180930.GA22066@redhat.com> User-Agent: Mutt/1.3.28i X-SW-Source: 2002-11/txt/msg00331.txt.bz2 > On Wed, Nov 06, 2002 at 06:54:41PM +0100, Jan Hubicka wrote: > > + For fast math it would be safe probably to convert (float)sqrt(x) > > + into sqrt((float)x), but in strict mode the argument can overflow. */ > > I don't believe this to be true. What you don't believe? That in ffast-math we can do the transformation? Right, that is possible. I am not sure whehter we can afford the possible overflow there. So I can drop the comment. > > > + /* Wind away possible cast. */ > > + if (TREE_CODE (arg0) == NOP_EXPR) > > + arg0 = TREE_OPERAND (arg0, 0); > > Why would you do this? This might be casting down to double from > long double. You should only strip casts when they widen the type. Right, I will add that. For some reason I believed that these are CONVERT. > > > + /* convert (outertype)((innertype0)a+(innertype1)b) > > + into ((newtype)a+(newtype)b) where newtype > > + is the widest mode from all of these. */ > > This changes overflow characteristics of +. Consider > > (double)((float)a + (float)b) > > where A = B = 2**127. The result should be +Inf, not 2**128. I am doing that only when the mode of + is wider. > > Finally, I think it is alarmingly incorrect that > > (float)((double)a + (double)b)) > > does not result in a quantity of type float, as requested. Here I do that. When a and b are floats, I will produce (a+b) is that wrong? Honza > > > r~