When SROA splits up composite types and individual pieces are described by integer constants, we currently default to emitting these constant pieces as unsigned bytes regardless of the encoding of the underlying types. We don't make any attempt to find the correct encoding by finding the underlying element type from the composite type.
In the attached testcase a complex float is split into two 64-bit *integers* (because the target doesn't define a 64-bit double type).
This patch relaxes the assertion in isUnsignedDIType and matches the behavior so complex_float is treated consistent with other composite types.
I agree that trusting the IR to encode integer constants properly is questionable, but it is consistent with what we do for composite types, and apparently we're not doing any better elsewhere:
void DwarfUnit::addConstantFPValue(DIE &Die, const ConstantFP *CFP) { // Pass this down to addConstantValue as an unsigned bag of bits. addConstantValue(Die, CFP->getValueAPF().bitcastToAPInt(), true); }
Thoughts?
Huh. So we see udata (0) because the zero value is considered as an integer type rather than a float type? And that's supposed to be the entire 128-bit value?
I wonder if something else weird is going on with _Complex, because on Linux I get DW_AT_location with an expression that describes only one 8-byte piece.