================
@@ -6418,6 +6418,12 @@ def warn_signed_bitfield_enum_conversion : Warning<
InGroup<BitFieldEnumConversion>, DefaultIgnore;
def note_change_bitfield_sign : Note<
"consider making the bitfield type %select{unsigned|signed}0">;
+def warn_ms_bitfield_mismatched_storage_packing : Warning<
+ "bit-field %0 of type %1 has a different storage size (%2 vs %3 bytes) than
the "
+ "preceding bit-field and may not be packed under MSVC ABI">,
+ InGroup<MSBitfieldCompatibility>, DefaultIgnore;
----------------
ojhunt wrote:
Oh, what are the semantics of `-fms-compatibility`? does it include the codegen
changing options? In which case I'm not sure if this warning should be on?
My intention for this warning was so that code that compiled under both ms and
and non-ms ABIs with the expectation of sane padding (e.g. llvm+clang) can
diagnose the padding difference.
But for someone compiling under the ms abi that's presumably the intent so the
warning becomes "you aren't packing these perfectly" (which might be something
to subsume into a more usual packing warning?), but enabling this warning by
default is basically going to mean we'll be making a warning along the lines of
"warning: packing of these fields matches the expected platform packing" which
seems less than great.
My long term goal is to allow us to switch to enum bitfields in llvm/clang
because we'll have warnings mitigating the issues that apparently caused us to
use unsigned instead of enums everywhere.
https://github.com/llvm/llvm-project/pull/117428
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
