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

[Richard Henderson <rth at redhat dot com>]

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,

> + 	  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);

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.



r~