nlopes added a comment.
In D128501#3613420 <https://reviews.llvm.org/D128501#3613420>, @efriedma wrote:
>> No, you can still link those. There's no ABI change nor any interference at
>> IR level.
>
> The scenario I was thinking of with -ffine-grained-bitfield-accesses is
> something like the following:
>
> File A:
>
> struct X { int a : 8; int b : 24; };
> void f(struct X*);
> int g() {
> struct X x;
> x.a = 10;
> f(&x);
> return x.a;
> }
>
> File B:
>
> struct X { int a : 8; int b : 24; };
> void f(struct X* x) {
> x->b = 10;
> }
>
> If both files are compiled -ffine-grained-bitfield-accesses, the fields don't
> overlap. If both files are compiled with
> -fno-fine-grained-bitfield-accesses, the assignment in file A freezes both
> fields of "x". If file A is compiled with -ffine-grained-bitfield-accesses,
> but file B is not, f() corrupts the field "a", so g() returns poison (if I'm
> not missing anything?).
You are right, thanks! f() corrupts `a` because f assumes the fields were both
initialized or neither of them was initialized.
The fix is not trivial though, because -ffine-grained-bitfield-accesses would
have to freeze the adjacent fields.
This only matters if the IRs are linked together with IPO. Otherwise, at object
level it doesn't really matter.
Do you think we can get away by just documenting the incompatibility of doing
IPO with files compiled with different -ffine-grained-bitfield-accesses flags?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D128501/new/
https://reviews.llvm.org/D128501
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
