2015-05-29 13:36 GMT+02:00 Riot <[email protected]>: > I have to disagree. I use lto in large production builds with great > success. My use case is performance critical (games) and I build with > -Ofast as well as lto and other heavy optimisations without problems, > generating executable binaries of over a hundred megabytes in size when > stripped and consisting of hundreds of translation units. > > Prior to 4.8 lto was incomplete and problematic but most bugs seem to have > been eradicated by gcc 5.0. >
Interesting, because lto, even on Linux, causes quite some grievances up to te point distributions are refusing to enable it for their packages by default. Would you have any performance numbers (and I guess file sizes) comparing lto vs no-lto builds (all the other options remaining unchanged of course)? It'd be very interesting to see how lto actually changes things. Thanks! Ruben > In my experience RTTI problems are more likely related to linking objects > that were built with a different version of gcc using lto. Try rebuilding > all your libraries and any linked objects with the same gcc version and > settings. It may also be worth it to try static linking. > > Riot > On 29 May 2015 12:21, "Etienne Sandré-Chardonnal" <[email protected]> > wrote: > >> 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
