- Generated by
1.8.1.1
|
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 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
warning. 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 | ( | ) |
@verbatim
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
-fmath-errno. 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-
floating-point-square-root 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.
1.8.1.1