That's difficult to know, since the debugger seems to miss some information. The current function where the crash occurs is unknown :?? in the level 1 stack view For levels 2,3 and 4 I have the function name, but I have no access to the location in the code. Only level 5 of the stack is fully working in the debugger (all symbols + location in code)
Level 2 is an default assignment operator of my ImageBuffer class. The class only contains basic types and std:: containers, no user defined pointers, so it likely crashes when copying one of the containers. The -flto is clearly not fully usable yet. I was trying it to see if it increases performance in a speed-critical app, which has a complex code and a lot of function calls between non-virtual classes. This seemed to be a good candidate for LTO. What did your debugger say? Was the segfault caused by dereferencing a pointer returned by a failed dynamic_cast? > > To my knowledge flto has never been working perfectly since g++ 4.8 on > Windows: multiple definitions, undefined references, pointer-to-function > referring garbage memory, valid pointers becoming null, random segment > faults, etc... > I strongly suggest you not use flto in production builds. > >
------------------------------------------------------------------------------
_______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
