[Bug target/70052] ICE compiling _Decimal128 test case

[amodra at gmail dot com]

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.)