Bug 83756

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.

GCC 11 branch is being closed.