tree.cc: Fix optimization of DFP default initialization

When an object of decimal floating-point type is default-initialized,
GCC is inconsistent about whether it is given the all-zero-bits
representation (zero with the least quantum exponent) or whether it
acts like a conversion of integer 0 to the DFP type (zero with quantum
exponent 0).  In particular, the representation stored in memory can
have all zero bits, but optimization of access to the same object
based on its known constant value can then produce zero with quantum
exponent 0 instead.

C2x leaves the quantum exponent for default initialization
implementation-defined, but that doesn't allow such inconsistency in
the interpretation of a single object.  All zero bits seems most
appropriate; change build_real to special-case dconst0 the same way
other constants are special-cased and ensure that the correct zero for
the type is generated.

Bootstrapped with no regressions for x86_64-pc-linux-gnu.

gcc/
	* tree.cc (build_real): Give DFP dconst0 the minimum quantum
	exponent for the type.

gcc/testsuite/
	* gcc.dg/torture/dfp-default-init-1.c,
	gcc.dg/torture/dfp-default-init-2.c,
	gcc.dg/torture/dfp-default-init-3.c: New tests.

0 files changed, 0 insertions, 0 deletions