GCC Middle and Back End API Reference

Functions  
tree  convert_to_pointer () 
tree  convert_to_real () 
tree  convert_to_integer () 
tree  convert_to_complex () 
tree  convert_to_vector () 
tree  convert_to_fixed () 
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 fixedpoint type TYPE. EXPR must be fixedpoint, 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, fixedpoint 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 3bit unsigned integer type, the TYPE is a 3bit signed integer type, and the machine mode for the types is 8bit QImode. In that case, the conversion necessitates an explicit signextension. In the signedtounsigned case the highorder 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 fullword 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 thisthe times when two narrow values can be combined in their narrow type even to make a wider resultare 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 warning.
If the original expression had sideeffects, 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 signedoverflow 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 signedoverflow 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  (  ) 
@verbatim
Utility routines for data type conversion for GCC. Copyright (C) 19872013 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 languageindependent utility function intended to be called by the languagespecific 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 floatingpoint type TYPE. EXPR must be float, fixedpoint, 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 fmatherrno.
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) to (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: http://stackoverflow.com/questions/9235456/determining floatingpointsquareroot
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 roundtonearest and can round up to the next integer.
Propagate the cast into the operation.
Convert (float)x into (float)x. This is safe for roundtonearest 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.