https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70052
Alan Modra <amodra at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |amodra at gmail dot com
--- Comment #3 from Alan Modra <amodra at gmail dot com> ---
Canonical dfp 0.0 is not all-zero bits in any mode due to the exponent bias. I
think that makes the "j" constraint broken for dfp, since it tests for the
canonical 0.0 but the insns load an all-zero bit pattern.
What's happening with the testcase is that the init-regs pass is providing a
zero for an undefined variable
(insn 82 16 17 2 (set (reg/v:TD 155 [ zz ])
(const_double:TD 0.0 [0x0.0p+0])) /src/tmp/pr70052.c:14 -1
(nil))
This gets split post-reload using rs6000_split_multireg_move, the
const_double:TD 0.0 being processed by simplify_gen_subreg into two DD
constants with the same bit patterns as the halves of the TD constant. Problem
is that the two DD constants are DD 0E-12 and DD 0E-398 neither of which is
exactly the same as DD 0.0.
I don't think we can change dfp 0.0 to be all-zero bits, because the current
bit pattern is produced by the hardware for 0.0, except possibly when
-funsafe-math-optimizations. (Exponent can be extracted, reg stored to memory
then bits examined.)
