dwarf2out: Fix debug info for 2 byte floats [PR99388]

dwarf2out: Fix debug info for 2 byte floats [PR99388]

Aarch64, ARM and a couple of other architectures have 16-bit floats, HFmode.
As can be seen e.g. on
void
foo (void)
{
  __fp16 a = 1.0;
  asm ("nop");
  a = 2.0;
  asm ("nop");
  a = 3.0;
  asm ("nop");
}
testcase, GCC mishandles this on the dwarf2out.c side by assuming all
floating point types have sizes in multiples of 4 bytes, so what GCC emits
is it says that e.g. the DW_OP_implicit_value will be 2 bytes but then
doesn't emit anything and so anything emitted after it is treated by
consumers as the value and then they get out of sync.
real_to_target which insert_float uses indeed fills it that way, but putting
into an array of long 32 bits each time, but for the half floats it puts
everything into the least significant 16 bits of the first long no matter
what endianity host or target has.

The following patch fixes it.  With the patch the -g -O2 -dA output changes
(in a cross without .uleb128 support):
        .byte   0x9e    // DW_OP_implicit_value
        .byte   0x2     // uleb128 0x2
+       .2byte  0x3c00  // fp or vector constant word 0
        .byte   0x7     // DW_LLE_start_end (*.LLST0)
        .8byte  .LVL1   // Location list begin address (*.LLST0)
        .8byte  .LVL2   // Location list end address (*.LLST0)
        .byte   0x4     // uleb128 0x4; Location expression size
        .byte   0x9e    // DW_OP_implicit_value
        .byte   0x2     // uleb128 0x2
+       .2byte  0x4000  // fp or vector constant word 0
        .byte   0x7     // DW_LLE_start_end (*.LLST0)
        .8byte  .LVL2   // Location list begin address (*.LLST0)
        .8byte  .LFE0   // Location list end address (*.LLST0)
        .byte   0x4     // uleb128 0x4; Location expression size
        .byte   0x9e    // DW_OP_implicit_value
        .byte   0x2     // uleb128 0x2
+       .2byte  0x4200  // fp or vector constant word 0
        .byte   0       // DW_LLE_end_of_list (*.LLST0)

Bootstrapped/regtested on x86_64-linux, aarch64-linux and
armv7hl-linux-gnueabi, ok for trunk?

I fear the CONST_VECTOR case is still broken, while HFmode elements of vectors
should be fine (it uses eltsize of the element sizes) and likewise SFmode could
be fine, DFmode vectors are emitted as two 32-bit ints regardless of endianity
and I'm afraid it can't be right on big-endian.  But I haven't been able to
create a testcase that emits a CONST_VECTOR, for e.g. unused vector vars
with constant operands we emit CONCATN during expansion and thus ...
DW_OP_*piece for each element of the vector and for
DW_TAG_call_site_parameter we give up (because we handle CONST_VECTOR only
in loc_descriptor, not mem_loc_descriptor).

2021-03-21  Jakub Jelinek  <jakub@redhat.com>

	PR debug/99388
	* dwarf2out.c (insert_float): Change return type from void to
	unsigned, handle GET_MODE_SIZE (mode) == 2 and return element size.
	(mem_loc_descriptor, loc_descriptor, add_const_value_attribute):
	Adjust callers.