With gcc-8.0.0 onwards, specifically commit ab87ee8f509c0b600102195704105d4d98ec59d9, the following test case fails to compile using either i686-w64-mingw32-g++ or x86_64-w64-mingw32-g++ (but compiles normally using the native x86_64-linux-g++): --- test.cpp --- template <typename ToCheck, unsigned ExpectedSize, unsigned RealSize = sizeof(ToCheck)> void check_size() { static_assert(ExpectedSize == RealSize, "Size is off!"); } struct Foo { unsigned u1 : 5; unsigned u2 : 5; unsigned u3 : 3; unsigned u4 : 3; unsigned u5 : 4; unsigned u6 : 2; unsigned u7 : 3; unsigned u8 : 2; unsigned u9 : 1; unsigned u10 : 3; // 31 bits unsigned u11 : 2; unsigned u12 : 2; unsigned u13 : 2; unsigned u14 : 6; unsigned u15 : 7; unsigned u16 : 1; unsigned u17 : 1; unsigned u18 : 1; unsigned u19 : 1; unsigned u20 : 1; bool bar() const { return false; } private: unsigned u21 : 1; unsigned u22 : 1; unsigned u23 : 1; unsigned u24 : 1; // 59 bits }; int main(int argc, char* argv[]) { check_size<Foo, 8>(); return 0; } ----- $ x86_64-w64-mingw32-g++ test.cpp -o test.exe test.cpp: In instantiation of 'void check_size() [with ToCheck = Foo; unsigned int ExpectedSize = 8; unsigned int RealSize = 12]': test.cpp:41:24: required from here test.cpp:3:30: error: static assertion failed: Size is off! static_assert(ExpectedSize == RealSize, "Size is off!"); Notice the presence of the bar member function. Without the member function, sizeof(Foo) = 8 as expected, but with the member function, sizeof(Foo) = 12.
CC nathan@acm.org as author of ab87ee8f509c0b600102195704105d4d98ec59d9
What changelog does that has refer to? (I don;t use the git repo)
See https://github.com/gcc-mirror/gcc/commit/ab87ee8f509c0b600102195704105d4d98ec59d9
That's r250413 Confirmed
what should the layout of the following be? struct Foo { unsigned one : 24; static int var; unsigned two : 4; }; is this size 8 or 4?
Created attachment 44623 [details] patch This patch appears to fix the problem It'd be good to (a) confirms it also passes on MS's compiler
Created attachment 44624 [details] this is the testcase
It compiles successfully with MSVC https://godbolt.org/z/Cw-yiW
(In reply to Nathan Sidwell from comment #6) > Created attachment 44623 [details] > patch > > This patch appears to fix the problem It'd be good to (a) confirms it also > passes on MS's compiler With this patch applied, GCC 8.2.1 accepts the testcase, as well as Microsoft CL 19.15.26726 .
gcc-8 patch posted https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01900.html
Author: nathan Date: Wed Sep 5 10:04:58 2018 New Revision: 264119 URL: https://gcc.gnu.org/viewcvs?rev=264119&root=gcc&view=rev Log: PR c++/87137] GCC-8 Fix https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01966.html PR c++/87137 * stor-layout.c (place_field): Scan forwards to check last bitfield when ms_bitfield_placement is in effect. gcc/testsuite/ * g++.dg/abi/pr87137.C: New. Added: trunk/gcc/testsuite/g++.dg/abi/pr87137.C Modified: trunk/gcc/ChangeLog trunk/gcc/stor-layout.c trunk/gcc/testsuite/ChangeLog
Fixed trunk r264119
Fixed gcc-8 r264123. changes.html remains to do
Author: nathan Date: Wed Sep 5 10:42:59 2018 New Revision: 264123 URL: https://gcc.gnu.org/viewcvs?rev=264123&root=gcc&view=rev Log: [PR c++/87137] GCC-8 Fix https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01966.html PR c++/87137 * stor-layout.c (place_field): Scan forwards to check last bitfield when ms_bitfield_placement is in effect. gcc/testsuite/ * g++.dg/abi/pr87137.C: New. Added: branches/gcc-8-branch/gcc/testsuite/g++.dg/abi/pr87137.C Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/stor-layout.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
I forgot to mark this fixed.
$ ./gdb -nx -q --data-directory=data-directory ~/a.out -ex "set confirm off" -ex "file -readnow ~/a.out" http://www-look-4.com/ Reading symbols from /home/simark/a.out... Reading symbols from ~/a.out... https://komiya-dental.com/ /home/simark/src/binutils-gdb/gdb/dwarf2/read.c:8098: internal-error: void create_all_comp_units(dwarf2_per_objfile*): Assertion `per_objfile->per_bfd- http://www.iu-bloomington.com/ >all_comp_units.empty ()' failed. This is a recurring problem that exposes a design issue https://waytowhatsnext.com/ / in the DWARF per-BFD sharing feature. Things work well when loading a binary with https://www.mktrade.fi/muottivalmistus the same method (with/without index, with/without readnow) twice http://www.wearelondonmade.com/ in a row. But they don't work so well when loading a binary with different methods. See this previous fix, for example: http://www.jopspeech.com/ efb763a5ea35 ("gdb: check for partial symtab presence in dwarf2_initialize_objfile") http://joerg.li/ That one handled the case where the first load is normal (uses partial symbols) and the second load uses an index. http://connstr.net/ The problem is that when loading an objfile with a method A, we create a dwarf2_per_bfd and some dwarf2_per_cu_data and initialize them with the http://embermanchester.uk/ data belonging to that method. When loading another obfile sharing the same BFD but with a different method B, it's not http://www.slipstone.co.uk/ clear how to re-use the dwarf2_per_bfd/dwarf2_per_cu_data previously created, because they contain the data specific to method A. http://www.logoarts.co.uk/ I think the most sensible fix would be to not share a dwarf2_per_bfd between two objfiles loaded with different methods. That means that two objfiles sharing the same BFD http://www.acpirateradio.co.uk/ and loaded the same way would share a dwarf2_per_bfd. Two objfiles sharing the same BFD but loaded with different methods would use two different dwarf2_per_bfd structures. http://www.compilatori.com/ However, this isn't a trivial change. So to fix the known issue quickly (including in the gdb 10 branch), this patch just disables all dwarf2_per_bfd sharing for objfiles using READNOW. Generalize the gdb.base/index-cache-load-twice.exp test to test all the possible combinations of loading a file with partial symtabs, index and readnow. Move it to gdb.dwarf2, https://www.webb-dev.co.uk/ since it really exercises features of the DWARF reader.