dwblaikie wrote:
> ```c++
> struct A {
> short a1;
> short a2;
> };
>
> struct B {
> [[clang::preferred_type(A)]] unsigned b1 : 32 = 0x000F'000C;
> };
>
> int main()
> {
> B b;
> return b.b1;
> }
> ```
An example where the layout doesn't match the normal struct layout might be
more interesting? (like the reality of this situation ^ seems indistinguishable
from similar code that used the real type and no bitfield, I think? (as far as
the DWARF,struct layouts, etc, are concerned)) - maybe a struct with a `short`
and a `char` (so it should have a byte of tail padding) then putting it in a 24
bit bitfield (maybe with an 8 bit bitfield after that - to check if attempts to
write to the first bitfielded struct don't clobber the following bits) - or,
maybe even a struct that ends in a bitfield so it's got less-than-whole-byte
padding at the end, and see how that overlaps with embedding that as a bitfield
in another struct with a subsequent bitfield.
I would guess a DWARF consumer might have more struggles there - though I Don't
think it means we shouldn't do it, just expect to have to fix debuggers for
this probably-rather-novel DWARF.
https://github.com/llvm/llvm-project/pull/69104
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
