GCC Middle and Back End API Reference
convert.c File Reference


tree convert_to_pointer ()
tree convert_to_real ()
tree convert_to_integer ()
tree convert_to_complex ()
tree convert_to_vector ()
tree convert_to_fixed ()

Function Documentation

tree convert_to_complex ( )
   Convert EXPR to the complex type TYPE in the usual ways.  

References error().

tree convert_to_fixed ( )
   Convert EXPR to some fixed-point type TYPE.

   EXPR must be fixed-point, float, integer, or enumeral;
   in other cases error is called.  
tree convert_to_integer ( )
   Convert EXPR to some integer (or enum) type TYPE.

   EXPR must be pointer, integer, discrete (enum, char, or bool), float,
   fixed-point or vector; in other cases error is called.

   The result of this is always supposed to be a newly created tree node
   not in use in any existing structure.  
     An INTEGER_TYPE cannot be incomplete, but an ENUMERAL_TYPE can
     be.  Consider `enum E = { a, b = (enum E) 3 };'.  
     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.  
             Only convert in ISO C99 mode.  
             Only convert in ISO C99 mode.  
             Only convert in ISO C99 mode.  
             Only convert nearbyint* if we can ignore math exceptions.  
             ... Fall through ...  
             Only convert in ISO C99 mode.  
     Convert (int)logb(d) -> ilogb(d).  
         Convert to an unsigned integer of the correct width first, and from
         there widen/truncate to the required type.  Some targets support the
         coexistence of multiple valid pointer sizes, so fetch the one we need
         from the type.  
         If this is a logical operation, which just returns 0 or 1, we can
         change the type of the expression.  
         If we are widening the type, put in an explicit conversion.
         Similarly if we are not changing the width.  After this, we know
         we are truncating EXPR.  
             If the precision of the EXPR's type is K bits and the
             destination mode has more bits, and the sign is changing,
             it is not safe to use a NOP_EXPR.  For example, suppose
             that EXPR's type is a 3-bit unsigned integer type, the
             TYPE is a 3-bit signed integer type, and the machine mode
             for the types is 8-bit QImode.  In that case, the
             conversion necessitates an explicit sign-extension.  In
             the signed-to-unsigned case the high-order bits have to
             be cleared.  
         If TYPE is an enumeral type or a type with a precision less
         than the number of bits in its mode, do the conversion to the
         type corresponding to its mode, then do a nop conversion
         to TYPE.  
         Here detect when we can distribute the truncation down past some
         arithmetic.  For example, if adding two longs and converting to an
         int, we can equally well convert both to ints and then add.
         For the operations handled here, such truncation distribution
         is always safe.
         It is desirable in these cases:
         1) when truncating down to full-word from a larger size
         2) when truncating takes no work.
         3) when at least one operand of the arithmetic has been extended
         (as by C's default conversions).  In this case we need two conversions
         if we do the arithmetic as already requested, so we might as well
         truncate both and then combine.  Perhaps that way we need only one.

         Note that in general we cannot do the arithmetic in a type
         shorter than the desired result of conversion, even if the operands
         are both extended from a shorter type, because they might overflow
         if combined in that type.  The exceptions to this--the times when
         two narrow values can be combined in their narrow type even to
         make a wider result--are handled by "shorten" in build_binary_op.  
             We can pass truncation down through right shifting
             when the shift count is a nonpositive constant.  
             We can pass truncation down through left shifting
             when the shift count is a nonnegative constant and
             the target type is unsigned.  
                 If shift count is less than the width of the truncated type,
                 really shift.  
                   In this case, shifting is like multiplication.  
                     If it is >= that width, result is zero.
                     Handling this with trunc1 would give the wrong result:
                     (int) ((long long) a << 32) is well defined (as 0)
                     but (int) a << 32 is undefined and would get a
                     If the original expression had side-effects, we must
                     preserve it.  
               Don't distribute unless the output precision is at least as big
               as the actual inputs and it has the same signedness.  
                   If signedness of arg0 and arg1 don't match,
                   we can't necessarily find a type to compare them in.  
                   Do not change the sign of the division.  
                   Either require unsigned division or a division by
                   a constant that is not -1.  
               Don't distribute unless the output precision is at least as big
               as the actual inputs.  Otherwise, the comparison of the
               truncated values will be wrong.  
                   If signedness of arg0 and arg1 don't match,
                   we can't necessarily find a type to compare them in.  
               Do not try to narrow operands of pointer subtraction;
               that will interfere with other folding.  
                   Do the arithmetic in type TYPEX,
                   then convert result to TYPE.  
                   Can't do arithmetic in enumeral types
                   so use an integer type that will hold the values.  
                   But now perhaps TYPEX is as wide as INPREC.
                   In that case, do nothing special here.
                   (Otherwise would recurse infinitely in convert.  
                       Don't do unsigned arithmetic where signed was wanted,
                       or vice versa.
                       Exception: if both of the original operands were
                       unsigned then we can safely do the work as unsigned.
                       Exception: shift operations take their type solely
                       from the first argument.
                       Exception: the LSHIFT_EXPR case above requires that
                       we perform this operation unsigned lest we produce
                       signed-overflow undefinedness.
                       And we may need to do it as unsigned
                       if we truncate to the original size.  
                           If we have !flag_wrapv, and either ARG0 or
                           ARG1 is of a signed type, we have to do
                           PLUS_EXPR, MINUS_EXPR or MULT_EXPR in an unsigned
                           type in case the operation in outprec precision
                           could overflow.  Otherwise, we would introduce
                           signed-overflow undefinedness.  
             This is not correct for ABS_EXPR,
             since we must test the sign before truncation.  
             Don't introduce a
             "can't convert between vector values of different size" error.  
             If truncating after truncating, might as well do all at once.
             If truncating after extending, we may get rid of wasted work.  
             It is sometimes worthwhile to push the narrowing down through
             the conditional and never loses.  A COND_EXPR may have a throw
             as one operand, which then has void type.  Just leave void
             operands as they are.  
         When parsing long initializers, we might end up with a lot of casts.
         Shortcut this.  

References build_call_expr(), builtin_mathfn_code(), function_c99_misc, mathfn_built_in(), strip_float_extensions(), and targetm.

tree convert_to_pointer ( )

Utility routines for data type conversion for GCC. Copyright (C) 1987-2013 Free Software Foundation, Inc.

This file is part of GCC.

GCC is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 3, or (at your option) any later version.

GCC is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with GCC; see the file COPYING3. If not see http://www.gnu.org/licenses/.

   These routines are somewhat language-independent utility function
   intended to be called by the language-specific convert () functions.  
   Convert EXPR to some pointer or reference type TYPE.
   EXPR must be pointer, reference, integer, enumeral, or literal zero;
   in other cases error is called.  
           If the pointers point to different address spaces, conversion needs
           to be done via a ADDR_SPACE_CONVERT_EXPR instead of a NOP_EXPR.  
           If the input precision differs from the target pointer type
           precision, first convert the input expression to an integer type of
           the target precision.  Some targets, e.g. VMS, need several pointer
           sizes to coexist so the latter isn't necessarily POINTER_SIZE.  

References error(), lang_hooks_for_types::type_for_size, and lang_hooks::types.

tree convert_to_real ( )
   Convert EXPR to some floating-point type TYPE.

   EXPR must be float, fixed-point, integer, or enumeral;
   in other cases error is called.  
     Disable until we figure out how to decide whether the functions are
     present in runtime.  
     Convert (float)sqrt((double)x) where x is float into sqrtf(x) 
               The above functions may set errno differently with float
               input or output so this transformation is not safe with
               The above functions are not safe to do this conversion.  
                 We have (outertype)sqrt((innertype)x).  Choose the wider mode from
                 the both as the safe type for operation.  
                 We consider to convert

                     (T1) sqrtT2 ((T2) exprT3)
                     (T1) sqrtT4 ((T4) exprT3)

                  , where T1 is TYPE, T2 is ITYPE, T3 is TREE_TYPE (ARG0),
                 and T4 is NEWTYPE.  All those types are of floating point types.
                 T4 (NEWTYPE) should be narrower than T2 (ITYPE). This conversion
                 is safe only if P1 >= P2*2+2, where P1 and P2 are precisions of
                 T2 and T4.  See the following URL for a reference:
                     The following conversion is unsafe even the precision condition
                     below is satisfied:

                     (float) sqrtl ((long double) double_val) -> (float) sqrt (double_val)
                 Be careful about integer to fp conversions.
                 These may overflow still.  
             Make sure (type)arg0 is an extension, otherwise we could end up
             changing (float)floor(double d) into floorf((float)d), which is
             incorrect because (float)d uses round-to-nearest and can round
             up to the next integer.  
     Propagate the cast into the operation.  
           Convert (float)-x into -(float)x.  This is safe for
           round-to-nearest rounding mode when the inner type is float.  
           Convert (outertype)((innertype0)a+(innertype1)b)
           into ((newtype)a+(newtype)b) where newtype
           is the widest mode from all of these.  
                     Sometimes this transformation is safe (cannot
                     change results through affecting double rounding
                     cases) and sometimes it is not.  If NEWTYPE is
                     wider than TYPE, e.g. (float)((long double)double
                     + (long double)double) converted to
                     (float)(double + double), the transformation is
                     unsafe regardless of the details of the types
                     involved; double rounding can arise if the result
                     of NEWTYPE arithmetic is a NEWTYPE value half way
                     between two representable TYPE values but the
                     exact value is sufficiently different (in the
                     right direction) for this difference to be
                     visible in ITYPE arithmetic.  If NEWTYPE is the
                     same as TYPE, however, the transformation may be
                     safe depending on the types involved: it is safe
                     if the ITYPE has strictly more than twice as many
                     mantissa bits as TYPE, can represent infinities
                     and NaNs if the TYPE can, and has sufficient
                     exponent range for the product or ratio of two
                     values representable in the TYPE to be within the
                     range of normal values of ITYPE.  
         Ignore the conversion if we don't need to store intermediate
         results and neither type is a decimal float.  

References build_call_expr(), fold(), mathfn_built_in(), strip_float_extensions(), and type().

tree convert_to_vector ( )
   Convert EXPR to the vector type TYPE in the usual ways.