http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47903
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed| |2011.02.26 15:35:05
AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-02-26
15:35:05 UTC ---
Created attachment 23479
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23479
gcc46-pr47903.patch
The problem is that for binary real_arithmetic calls other than min/max the
padding bits (on 64-bit arches there are e.g. 32 bits in between uexp and sig)
are left uninitialized (for min/max/negate/abs we copy one of the arguments to
the result first). If the target hasn't been initialized before, is an
automatic variable and we then build_real from it (or construct CONST_DOUBLE),
the padding bits are left uninitialized.
Some functions are already taking care of initializing the padding, e.g.
real_value_from_int_cst, or get_inf, or real_nan, many others start by copying
some earlier REAL_VALUE_TYPE to the result first. real_arithmetic calls
with PLUS/MINUS/MULT/RDIV can't do that easily (because the result might be
same as either of the operands which will be still needed), so this patch
changes the callers of that function where this problem happens (const_binop)
or where IMHO might happen (the rest).
