This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Simplify floating point conversions II


> 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~


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]