[PATCH] Move folding of round -> lround from convert.c to fold_unary

[Richard Guenther]

On Mon, 12 Dec 2005, Richard Henderson wrote:

> On Wed, Dec 07, 2005 at 01:47:10PM +0100, Richard Guenther wrote:
> > +       /* Convert e.g. (long)round(d) -> lround(d).  */
> > +       /* If we're converting to char, we may encounter differing behavior
> > + 	 between converting from double->char vs double->long->char.
> > + 	 We're in "undefined" territory but we prefer to be conservative,
> > + 	 so only proceed in "unsafe" math mode.  */
> > +       if (optimize
> > + 	  && TREE_CODE (op0) == CALL_EXPR
> > + 	  && TREE_CODE (type) == INTEGER_TYPE
> > + 	  && (flag_unsafe_math_optimizations
> > + 	      || (long_integer_type_node
> > + 		  && (TYPE_PRECISION (type)
> > + 		      >= TYPE_PRECISION (long_integer_type_node)))))
> 
> Um, shouldn't type have *less* precision than long?
> 
> Suppose long is 32 bits.  Suppose type is 64 bits.  When
> converting 1p62, we don't want the value truncated.  The
> code appears to try to handle this,

The check above is because of the comment that we don't want to
do f.i. (short)lround(double) instead of (short)round(double) because
of precision issues.  I think it is somewhat bogus, as likely there's
no direct way of double -> short conversion available, but this was
just copied over from the convert.c variant.

> > + 	  bool ll = (TYPE_MAIN_VARIANT (type)
> > + 		     == TYPE_MAIN_VARIANT (long_long_integer_type_node));
> 
> but will fail for types larger than long long (e.g. TImode),
> and for certain kinds of bitfields:
>
> 	struct {
> 	  long long x : 52;
> 	} s;
> 	s.x = round(d);

Hmm, yes.  I originally had these identified by TYPE_PRECISION <=
that of long_long_integer_type_node.  I'll rework to avoid using
the type main variant here and not convert for integer types
larger than long long.
 
> Finally, long_integer_type_node only makes sense for C/C++.
> It is in fact definitely wrong for Java.  We probably ought to 
> clarify this by creating c_long_integer_type_node and friends,
> and also moving the C builtins someplace generic; in general 
> all languages are liking to take advantage of the C runtime.

Yes, this sounds like a good idea.  How should I proceed here
wrt the moving of stuff from convert.c to fold-const.c?

Richard.