Created attachment 43076 [details] Original sanitized output - The exact version of GCC: x86_64-5.4.0-release-win32-seh-rt_v5-rev0. I was able to reproduce also on 4.9.4 and 7.2.0 equivalents but I forgot to write the exact versions. I tried to keep the toolchains as equal as possible except for versions. I can get exact names if you guys need them. The maintainer of mingw64 said they could also reproduce on 7.2.1, and said it's a vanilla gcc bug which is why it's here. - The system type: Windows 7 64-bit, Intel - The options given when GCC was configured/built: This is a mingw-w64-distributed build: Configured with: ../../../src/gcc-5.4.0/configure --host=x86_64-w64-mingw32 --build=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --prefix=/mingw64 --with-sysroot=/c/mingw540/x86_64-540-win32-seh-rt_v5-rev0/mingw64 --with-gxx-include-dir=/mingw64/x86_64-w64-mingw32/include/c++ --enable-shared --enable-static --disable-multilib --enable-languages=c,c++,fortran,lto --enable-libstdcxx-time=yes --enable-threads=win32 --enable-libgomp --enable-libatomic --enable-lto --enable-graphite --enable-checking=release --enable-fully-dynamic-string --enable-version-specific-runtime-libs --disable-isl-version-check --disable-libstdcxx-pch --disable-libstdcxx-debug --enable-bootstrap --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-gnu-as --with-gnu-ld --with-arch=nocona --with-tune=core2 --with-libiconv --with-system-zlib --with-gmp=/c/mingw540/prerequisites/x86_64-w64-mingw32-static --with-mpfr=/c/mingw540/prerequisites/x86_64-w64-mingw32-static --with-mpc=/c/mingw540/prerequisites/x86_64-w64-mingw32-static --with-isl=/c/mingw540/prerequisites/x86_64-w64-mingw32-static --with-pkgversion='x86_64-win32-seh-rev0, Built by MinGW-W64 project' --with-bugurl=http://sourceforge.net/projects/mingw-w64 CFLAGS='-O2 -pipe -I/c/mingw540/x86_64-540-win32-seh-rt_v5-rev0/mingw64/opt/include -I/c/mingw540/prerequisites/x86_64-zlib-static/include -I/c/mingw540/prerequisites/x86_64-w64-mingw32-static/include' CXXFLAGS='-O2 -pipe -I/c/mingw540/x86_64-540-win32-seh-rt_v5-rev0/mingw64/opt/include -I/c/mingw540/prerequisites/x86_64-zlib-static/include -I/c/mingw540/prerequisites/x86_64-w64-mingw32-static/include' CPPFLAGS= LDFLAGS='-pipe -L/c/mingw540/x86_64-540-win32-seh-rt_v5-rev0/mingw64/opt/lib -L/c/mingw540/prerequisites/x86_64-zlib-static/lib -L/c/mingw540/prerequisites/x86_64-w64-mingw32-static/lib ' - The complete command line that triggers the bug: Really barely anything. I'm using gradle to build so it's nothing fancy: -x c++ -c -DCLASSA_EXPORT -DCLASSB_IMPORT -std=c++11 -I <lots of includes here> -m64 the compiler output (error messages, warnings, etc.): I've attached the original output.
Obviously you need a way to reproduce this bug. The original comment does not include that information. I'm going to attach a minimal test case, instructions on how to run it, and the .ii to make it even easier.
Created attachment 43077 [details] Minimal test case With: x86_64-w64-mingw32-g++ -std=c++11 -I path/to/official/boost/1.57/includes/ -L path/to/official/boost/1.57/64bit/libraries/ TestClass.cpp I am able to reproduce the failure. See the attached file for the minimal test case.
Created attachment 43078 [details] mingw-w64 5.4.0 TestClass.ii I've attached gcc's intermediate output to make this even easier to reproduce. Compile it like so: x86_64-5.4.0-release-win32-seh-rt_v5-rev0/mingw64/bin/g++ -std=c++11 TestClass.ii
Created attachment 43080 [details] 7.2.0 test case output This is output from a 7.2.0 run. It produces the same crash.
Created attachment 43081 [details] mingw-w64 7.2.0 TestClass.ii This is the intermediate output from a 7.2.0 run.
usual size_t massaging is not enough to amke it compile with x86_64-linux, I run into bin/boost-win64-1.57/boost/thread/win32/shared_mutex.hpp:49:13: error: static assertion failed: sizeof(T)==sizeof(long) so likely mingw (cross?) required to reproduce. The ICE looks like we might have a dup as well.
Richard, I ran into the same issues trying to reproduce on Linux. The problem is the code here relies on boost/thread which uses all Windows-specific typing and API, which is nicely pointed out by boost devs with that assert. I've mangled the .ii file to compile and it bypasses the crash as well. This is the mingw-w64 toolchain I've been using (visit with a browser to get a mirror selected): https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/7.2.0/threads-win32/seh/x86_64-7.2.0-release-win32-seh-rt_v5-rev0.7z Let me know if you need me to do anything to help with this bug.
This is a pointer to member function with -fms-extensions issue. I am reducing, the ICE can still be seen on the trunk.
(In reply to Andrew Pinski from comment #8) > This is a pointer to member function with -fms-extensions issue. > > I am reducing, the ICE can still be seen on the trunk. I should mention I was able to reproduce the failure on x86_64-linux even though the testcase needed some changes to get the failure there.
This is not the best reduced testcase because the original one was accepted without -fms-extensions. template <class Fp, class A0> auto invoke(Fp && f, A0 && a0) -> decltype(*(a0).*f) { return (*(a0)).*f; } struct A{ void doB(); }; void g() { A a; invoke(&A::doB, &a); } ---- CUT ---- Let me find one which is accepted with -fms-extensions.
Reduced testcase: template <class Fp, class A0, class ...Args> inline auto invoke(Fp && f, A0 && a0, Args && ...args) -> decltype(((*(a0)).*f)((args)...)) { } template <class Fp, class A0> inline auto invoke(Fp && f, A0 && a0) -> decltype((*(a0)).*f) { return (*(a0)).*f; } struct A { void doA(); void doB() { } }; void A::doA() { invoke(&A::doB, this); }
This is a regression from 4.8.5.
*** Bug 85776 has been marked as a duplicate of this bug. ***
*** Bug 69832 has been marked as a duplicate of this bug. ***
GCC 9 branch is being closed
GCC 10.4 is being released, retargeting bugs to GCC 10.5.
Re-confirmed. The gimplifier sees (gdb) p debug_tree (*expr_p) <offset_ref 0x7ffff64320a0 type <method_type 0x7ffff642a498 type <void_type 0x7ffff6289f18 void type_6 VOID ... (gdb) p debug_generic_expr (*expr_p) <<< Unknown tree: offset_ref **a0 *f >>> which supposedly is not to survive this long.
GCC 10 branch is being closed.