Microsoft ABI Support vs. ms_struct & Removing -mms-bitfields

Now that I’m putting finishing touches on the Microsoft Record Layout patch (http://llvm-reviews.chandlerc.com/D1026) there are some subtle issues that are cropping up with respect to compatibility with the ms_struct pragma/mms-bitfields flag.

The issues is that behavior of ms_struct/mms-bitfields is to use the Itanium layout rules for everything except alignment of long long, bitfields and bitfield padding. This results in something that is Win32 ABI compatible for standard layout C++ structures but not otherwise.

It would be a maintenance win if we could remove all Microsoft related layout code from the Itanium builder and simply use the Microsoft builder when ms_struct or mms-bitfields is set.

Does anyone object to making mms-bitfields/ms_struct mean “use Microsoft record layout” so we can deprecate the hybrid code?

When using mms-bitfields/ms_struct should we throw an error if the record is not standard layout?

Can we get rid of mms-bitfields in favor of ms_struct? Is anyone using mms-bitfields? Because mms-bitfields is global, it applies to the entire #include chain for a TU and can cause system structs etc to be laid out incorrectly and potentially silently break standard library interfaces/linking to TUs that don’t have mms-bitfields, etc.

-Warren

Can we get rid of mms-bitfields in favor of ms_struct? Is anyone using mms-bitfields? Because mms-bitfields is global, it applies to the entire #include chain for a TU and can cause system structs etc to be laid out incorrectly and potentially silently break standard library interfaces/linking to TUs that don't have mms-bitfields, etc.

Will this break compatibility with mingw? If yes, then mms-bitfields
should stay.

Do you mean command line or ABI compatibility? Whatever mingw does for bitfield layout, we should match it when the triple says mingw. Users shouldn’t have to add -mms-bitfields. I’d have to double check its layout.

Both actually. Given that -mms-bitfields is a valid gcc option we also
need to support it.

We don’t have to support every GCC feature. Only ones that people actually rely on and impede compatibility. The question is whether this is such a feature. To understand this, we need to understand use cases.

As far as I remember, gcc 4.7 defaults to -mms-bitfields, prior
versions - to -mno-ms-bitfields. So, it might be useful feature for
ABI compatibility (yes, this was pretty weird solution from gcc side,
as it seems to me)...

Now that I'm putting finishing touches on the Microsoft Record Layout
patch (http://llvm-reviews.chandlerc.com/D1026) there are some subtle
issues that are cropping up with respect to compatibility with the
ms_struct pragma/mms-bitfields flag.

The issues is that behavior of ms_struct/mms-bitfields is to use the
Itanium layout rules for everything except alignment of long long,
bitfields and bitfield padding. This results in something that is Win32
ABI compatible for standard layout C++ structures but not otherwise.

It would be a maintenance win if we could remove all Microsoft related
layout code from the Itanium builder and simply use the Microsoft builder
when ms_struct or mms-bitfields is set.

Does anyone object to making mms-bitfields/ms_struct mean "use Microsoft
record layout" so we can deprecate the hybrid code?

These are equivalent for standard-layout classes, right?

When using mms-bitfields/ms_struct should we throw an error if the record
is not standard layout?

Please be cautious here; even if we just consider clang on the Mac,
ms_struct is widely used, and some people probably use it on
non-standard-layout classes, either by accident or just without thinking
about it. And I'm sure a few people who haven't really considered the
consequences use -mms-bitfields as well.

-Eli

If people are using ms_struct and non-standard layouts without thinking about it then perhaps it is reasonable to force them to think about it? The ms_struct pragma is an ABI change, which has somewhat wide-reaching consequences. I suspect that the most common use case is to read serialized data directly into memory. I’m assuming that the data was serialized by code generated by the cl.exe (which is why they’re using ms-struct in the first place) and so they’re likely to get ms layout for non-standard layout types in the serialized data and might have bugs.

-Warren

I doubt anyone is actually directly serializing structs with vptrs. :slight_smile: I
just expect that the pragmas might cover more than they should.

It's not unreasonable to force people to think about it, but we probably
need some sort of deprecation period.

-Eli