dwblaikie wrote:
> > I'm arguing it doesn't fit it particularly well. We use it for bit fields -
> > which are pretty special, for instance, but it seems like this thing isn't
> > quite like that - it does have a whole byte size (if you allocated an array
> > of them, for instance, I'm
adrian-prantl wrote:
> I'm arguing it doesn't fit it particularly well. We use it for bit fields -
> which are pretty special, for instance, but it seems like this thing isn't
> quite like that - it does have a whole byte size (if you allocated an array
> of them, for instance, I'm guessing
dwblaikie wrote:
> > I guess one question that might be relevant - does Swift have something
> > like sizeof and what result does it give for these sort of types with bits
> > to spare?
>
> You can't actually use that with these types as these are special compiler
> builtin types which
augusto2112 wrote:
> I guess one question that might be relevant - does Swift have something like
> sizeof and what result does it give for these sort of types with bits to
> spare?
You can't actually use that with these types as these are special compiler
builtin types which aren't actually
dwblaikie wrote:
> @dwblaikie I talked with Adrian, his idea is to emit the size in bits
> whenever it does not cleanly fit in a byte. His point (and I agree) is that
> there may be tools that can use this bit size, and if we always round up when
> emitting the DWARF we will lose this
@@ -2866,8 +2879,12 @@ void DWARFASTParserClang::ParseSingleMember(
// Get the parent byte size so we can verify any members will fit
const uint64_t parent_byte_size =
parent_die.GetAttributeValueAsUnsigned(DW_AT_byte_size, UINT64_MAX);
- const uint64_t
