This is an archive of the discontinued LLVM Phabricator instance.

[AST] Fix compilation with GCC < 8 for MinGW
ClosedPublic

Authored by mstorsjo on Dec 18 2019, 1:01 AM.

Details

Summary

GCC 7 and earlier, when targeting MinGW, seems to have a bug in layout/size of bitfield structs if they contain a nested enum, making the size of the struct 8 bytes, while we have a static assert requiring it to be 4 bytes or less.

While this clearly is a GCC bug, the workaround (moving the enum out of the bitfield) also is very nonintrusive and matches other existing enums there.

Testcase:

$ cat bitfield.cpp
struct MyStruct {
  unsigned a : 1;
  enum { SomeValue = 42 };
  unsigned b : 1;
};      
int StructSize = sizeof(struct MyStruct);
$ x86_64-w64-mingw32-g++ -S -o - bitfield.cpp | grep -C 2 StructSize 
        .file   "bitfield.cpp"
        .text
        .globl  StructSize
        .data
        .align 4
StructSize:
        .long   8 
        .ident  "GCC: (GNU) 7.3-win32 20180312"

Diff Detail

Event Timeline

mstorsjo created this revision.Dec 18 2019, 1:01 AM
Herald added a project: Restricted Project. · View Herald TranscriptDec 18 2019, 1:01 AM

Wow, that's novel. Please add a comment explaining that this is a compiler workaround, but otherwise LGTM.

Wow, that's novel. Please add a comment explaining that this is a compiler workaround, but otherwise LGTM.

The post-patch form doesn't look that odd to me (and we wouldn't want one comment for every one of the existing enums that already are outside of the structs where they are used for bitfield sizes), but do you think a comment is warranted here on this one?

Wow, that's novel. Please add a comment explaining that this is a compiler workaround, but otherwise LGTM.

The post-patch form doesn't look that odd to me (and we wouldn't want one comment for every one of the existing enums that already are outside of the structs where they are used for bitfield sizes), but do you think a comment is warranted here on this one?

I think having a comment somewhere up there to say clearly that these things are hoisted up there as a workaround for a specific GCC port might help somebody from making this mistake again. It also might not, but certainly not having a comment can't help.

rnk added a comment.Dec 18 2019, 11:10 AM

I agree, in this case I think the comment will just be extra noise. The comment is likely to outlive the use of these buggy GCC versions. If someone runs into this bug again, it will probably happen somewhere else far away from this code, and the comment isn't going to help them avoid it.

I feel similarly about some MSVC workaround comments. The one that comes to mind is the fact that MSVC always gives unfixed enums the underlying type of int. We shouldn't sprinkle comments about this everywhere, we should document it once well in CodingStandards or something. In this case, I'm not sure we even need that. It seems like something better caught by a static assert.

We do have a static assert. I won't insist on the comment.

Ok, so if you're in agreement on this one, can either of you give the stamp of approval? :-)

rnk accepted this revision.Dec 18 2019, 1:43 PM

Pushing code review approval button.

This revision is now accepted and ready to land.Dec 18 2019, 1:43 PM
This revision was automatically updated to reflect the committed changes.