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: Scalar vector binary operation


On Mon, 15 Nov 2010, Artem Shinkarov wrote:

> -/* Warns if the conversion of EXPR to TYPE may alter a value.
> -   This is a helper function for warnings_for_convert_and_check.  */
> -
> -static void
> -conversion_warning (tree type, tree expr)
> +/* Return true if expression EXPR cannot be converted to the type TYPE
> +   preserving its value. Funtion will produce warnings if PRODUCE_WARNS

"Function"

> +   is true.  */
> +bool
> +unsafe_conversion_p (tree type, tree expr, bool produce_warns)

Are you sure the comment accurately describes the semantics?  The 
impression I get is that the new function is deliberately more restricted 
in the expressions it takes and the intelligence it applies to them than 
the old one - so the comment should say so (the point of the function 
being to give warnings according to some well-defined semantics and *not* 
to be smart in ways that may change unpredictably; the comment should make 
the semantics clear) - and that some cases may not return true even when 
you give a warning if produce_warns.

> @@ -1917,11 +1879,17 @@ conversion_warning (tree type, tree expr
>          {
>            if (TYPE_UNSIGNED (type) && !TYPE_UNSIGNED (expr_type)
>  	      && tree_int_cst_sgn (expr) < 0)
> -	    warning_at (loc, OPT_Wsign_conversion, "negative integer"
> -			" implicitly converted to unsigned type");
> +            {
> +              if (produce_warns)
> +	        warning_at (loc, OPT_Wsign_conversion, "negative integer"
> +		            " implicitly converted to unsigned type");

Here for example.  If this returns true, what logic causes it to do so?  
If not, why not?  (This sort of thing should best be made clear by 
comments in the code.)

> +        else if (!integer_only_op
> +                    /* Allow integer --> real conversion if safe.  */
> +                 && (TREE_CODE (type0) == REAL_TYPE 
> +                     || TREE_CODE (type0) == INTEGER_TYPE)
> +                 && SCALAR_FLOAT_TYPE_P (TREE_TYPE (type1)))
> +          {
> +            if (unsafe_conversion_p (TREE_TYPE (type1), op0, false))
> +              {
> +                error_at (loc, "truncating floating point constant to "
> +                               "vector precision does not preserve value");

"floating-point" when used as an adjective.

If you have an int constant that cannot be exactly converted to float, 
what error do you get for converting it to a float vector?  This one 
(which would be inappropriate since it's not a floating-point constant), 
or another one?  And is there a testcase for this?

-- 
Joseph S. Myers
joseph@codesourcery.com


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