Bug 83756

Summary: [12/13/14/15 Regression] gcc ICE in gimplify_expr on boost::call_once (-fms-extensions)
Product: gcc Reporter: Jacob Godserv <jacobgodserv>
Component: c++Assignee: Not yet assigned to anyone <unassigned>
Status: NEW ---    
Severity: normal CC: daniel.kruegler, lh_mouse, sonoro, webrown.cpp
Priority: P2 Keywords: ice-on-valid-code
Version: 7.2.0   
Target Milestone: 12.5   
See Also: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65568
Host: Target:
Build: Known to work: 4.7.1, 4.8.1, 4.8.5
Known to fail: 4.9.0, 7.2.1 Last reconfirmed: 2023-01-19 00:00:00
Bug Depends on: 65572    
Bug Blocks:    
Attachments: Original sanitized output
Minimal test case
mingw-w64 5.4.0 TestClass.ii
7.2.0 test case output
mingw-w64 7.2.0 TestClass.ii

Description Jacob Godserv 2018-01-09 16:20:57 UTC
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.
Comment 1 Jacob Godserv 2018-01-09 16:22:07 UTC
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.
Comment 2 Jacob Godserv 2018-01-09 16:28:45 UTC
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.
Comment 3 Jacob Godserv 2018-01-09 16:31:41 UTC
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
Comment 4 Jacob Godserv 2018-01-09 16:39:38 UTC
Created attachment 43080 [details]
7.2.0 test case output

This is output from a 7.2.0 run. It produces the same crash.
Comment 5 Jacob Godserv 2018-01-09 16:40:31 UTC
Created attachment 43081 [details]
mingw-w64 7.2.0 TestClass.ii

This is the intermediate output from a 7.2.0 run.
Comment 6 Richard Biener 2018-01-10 09:50:20 UTC
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.
Comment 7 Jacob Godserv 2018-01-15 16:40:52 UTC
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.
Comment 8 Andrew Pinski 2021-12-02 07:28:57 UTC
This is a pointer to member function with -fms-extensions issue.

I am reducing, the ICE can still be seen on the trunk.
Comment 9 Andrew Pinski 2021-12-02 07:30:55 UTC
(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.
Comment 10 Andrew Pinski 2021-12-02 07:58:19 UTC
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.
Comment 11 Andrew Pinski 2021-12-02 11:20:01 UTC
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);
}
Comment 12 Andrew Pinski 2021-12-02 11:27:31 UTC
This is a regression from 4.8.5.
Comment 13 Andrew Pinski 2021-12-03 02:32:30 UTC
*** Bug 85776 has been marked as a duplicate of this bug. ***
Comment 14 Andrew Pinski 2021-12-06 06:09:18 UTC
*** Bug 69832 has been marked as a duplicate of this bug. ***
Comment 15 Richard Biener 2022-05-27 09:38:00 UTC
GCC 9 branch is being closed
Comment 16 Jakub Jelinek 2022-06-28 10:34:09 UTC
GCC 10.4 is being released, retargeting bugs to GCC 10.5.
Comment 17 Richard Biener 2023-01-19 14:04:37 UTC
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.
Comment 18 Richard Biener 2023-07-07 10:32:52 UTC
GCC 10 branch is being closed.
Comment 19 Richard Biener 2024-07-19 13:01:03 UTC
GCC 11 branch is being closed.