Re: [Mingw-w64-public] Multiple definition issue with -flto, MinGW-w64 4.9.1
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. -- Best regards, lh_mouse 2015-05-29 - 发件人：Etienne Sandré-Chardonnal etienne.san...@m4x.org 发送日期：2015-05-29 00:33 收件人：mingw-w64-public 抄送： 主题：Re: [Mingw-w64-public] Multiple definition issue with -flto, MinGW-w64 4.9.1 Hi, This worked, the program compiles fine now. It crashes with a SegFault shortly after starting a new thread (via QThread), with a message: RTTI symbol not found for class 'SimClientPrivate' Are there incompatibilities of flto and cases where it cannot work? Thanks FWIW, you can try moving virtual function definitions out of header files, as defining virtual functions inside headers is generally a bad idea. (The story is much longer than that. Since the RTTI data of a polymorphic class is linked/exported/whatever with one of its virtual functions, specific mechanisms that rely on RTTI - dynamic_cast, exceptions, etc - might fail if RTTI of the same class is used across dynami clibrary boundaries.) -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Preferred build system, installation methods and download page links.
Hi, I am the main developer of Win-builds. NB 1: I slept 4 hours NB 2: I'll be away from keyboard, maybe for 24 hours On Fri, May 29, 2015, Prasanna V. Loganathar wrote: Hi, I had been using the builds as a part of MSYS2 for a while now, and I believe this is the most robust and easiest way to install mingw-w64. Also, due to the inherent nature of the system, it also provides the most up-to-date builds on par with the Linux builds. The build I see on winbuilds is actually older than the one on MSYS2. I'm just wondering if it would be in the best interests of the entire community that MSYS2 be promoted as the preferred build from the website instead of winbuilds. While win-builds seem to provide a GUI and switchable toolchain, MSYS2 just feels a lot more robust with, especially pacman. Pacman integration at its crux, seems to be the most brilliant package management strategy for windows, so far. First of all, talking only about gcc, mingw-w64 and binutils is very restrictive. All the builds have much more than that. It's fairly common to hear that toolchain X is older than toolchain Y. But first of all, does this even matter? Is there a bug with the GCC 4.8 branch? Or with mingw-w64 3.x? Or something else? If so, it should be fixed upstream and backported to the currently-supported releases. As far as I can tell, things work fairly well that way in practice. MSYS2 is a rolling-release distribution. It will most certainly be more up-to-date that win-builds but that's by design: both from msys2 and win-builds. Win-builds has full releases which are maintained. This means two things: once you start using one version, you don't get major software updates all of the time and can therefore get security and stability updates for a while without having to update between major software releases. The drawback is that updates are filtered and the larger they are, the less likely they are to be applied. When the currently-visible version of win-builds was made, GCC 4.9 was already available. It was a deliberate decision to /not/ use it because at that time, while not providing anything new that was usable, it had serious stability issues. By the way, GCC 5 does not have the same ABI as GCC 4.x for C++. Therefore every C++ code will need a rebuild. It's a major change and not necessarily something you want to see happen while you're developing your code. The wish for more updates has been acknowledged in win-builds: there is now a next repository which is the current development status. It should be at least as stable as what can be obtained through msys2 but it's not a win-builds release with a version: it's the in-progress repo. By the looks of the websites, I believe I can assume that the maintainers of winbuilds and mingw-w64 are the same or perhaps at the least linked. As I said, I am the main maintainer of win-builds. I am also the main maintainer of the website but it's been free for many many people to edit for quite some time (and even more now that it's actually a wiki). For the little story, for the look part: I migrated win-builds.org from self-made html/php to dokuwiki fairly quickly, got positive feedback except for the theme which looked too much like a wiki, found another one which pleased pretty much everyone. Then I tried to make yet another minor update to the old website and that was really too much suffering. Considering dokuwiki had been very easy to set up a few weeks earlier for win-builds.org, I made a proof-of-concept port for the website. Ate my week-end but worked. Waited a bit to get some feedback and then switched the websites. But I would very much like to think that it would be better to focus the efforts on one if so, and perhaps may be even implement winbuilds over msys2's excellent convergence work. But until then, I think it may make a lot more sense to converge with MSYS2 for official sources, rather than use the winbuilds system. Windows GCC (MinGW) builds of libraries have historically been a pain, because of the numerous different possible configuration the default build could have had, and due to the nature of the various sources, and none to be so-called official (or at-least a de-facto standard). Having winbuilds, and MSYS2 could again promote such problems, while converging them could very easily become the de-facto standard. Win-builds has other differences compared to msys2. One of them is that it's pretty much platform-agnostic. It started as a cross-compilation years ago (way way earlier than msys2) and the fact that it has a toolchain that runs on windows is a very small part of the whole project. Win-builds supports very well the scenario where you build from a sane operating system (say Linux) and want to have windows binaries: it makes it easy to build on your preferred system and deploy on Windows. The build times are also much shorter that way. It has been thought as a way to simplify the build of free software for
Re: [Mingw-w64-public] Multiple definition issue with -flto, MinGW-w64 4.9.1
2015-05-29 13:36 GMT+02:00 Riot rain.back...@gmail.com: 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 etienne.san...@m4x.org 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Multiple definition issue with -flto, MinGW-w64 4.9.1
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. 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 etienne.san...@m4x.org 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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Multiple definition issue with -flto, MinGW-w64 4.9.1
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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [[ noreturn ]]
On 05/28/2015 08:46 PM, Hotmail (ArbolOne) wrote:
Hi!
When using this the [[ noreturn ]] attribute like this: - void f [[
noreturn ]] (); - I get a warning that reads:
warning: 'noreturn' function does return
( http://www.stroustrup.com/C++11FAQ.html#attributes )
What can I do to remove this warning?
I don't see a warning for the example with GCC 4.8, 4.9, or
5.1. If you do, it might help if you posted the version of
GCC you're using and the command line options (for example,
like I did below). You could also check Bugzilla for known
noreturn bugs (though I couldn't find anything relevant).
Martin
$ cat t.cpp g++ -v g++ -Wall -Wextra -c -pedantic -std=c++11 t.cpp
void f [[ noreturn ]] () { throw error; }
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/ppc64-redhat-linux/4.8.3/lto-wrapper
Target: ppc64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap
--enable-shared --enable-threads=posix --enable-checking=release
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-linker-hash-style=gnu
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto
--enable-plugin --enable-initfini-array --disable-libgcj
--with-isl=/builddir/build/BUILD/gcc-4.8.3-20140911/obj-ppc64-redhat-linux/isl-install
--with-cloog=/builddir/build/BUILD/gcc-4.8.3-20140911/obj-ppc64-redhat-linux/cloog-install
--enable-gnu-indirect-function --enable-secureplt --with-long-double-128
--with-cpu-32=power7 --with-tune-32=power7 --with-cpu-64=power7
--with-tune-64=power7 --build=ppc64-redhat-linux
Thread model: posix
gcc version 4.8.3 20140911 (Red Hat 4.8.3-9) (GCC)
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Multiple definition issue with -flto, MinGW-w64 4.9.1
Oh I can absolutely see why you might not want to enable it by default, but in special cases where performance is worth the extra manual fuss of working around its very occasional bugs, it's quite useful. So I did a release build of our current primary project without LTO, and compared it to our build with LTO. Before I present the results though, some peculiarities of our build process to be aware of: - We compile all our libraries statically, including libc and libc++ under windows. In addition we make heavy use of templates and Boost, so our resulting generated object size is large. - We include large binary blobs in our release executable itself (game music, textures) which increase the final binary size considerably. I subtract these (approximate) blob sizes from the final result for the code size difference comparison. - There are no debugging symbols included in our release build and the binary is stripped with strip -spv. - This version is 32bit only. You may see very different results for 64bit builds. Project properties: - 27000LOC without includes - 200 compiled objects for the linker - 26 pre-compiled libraries, 9.27MB - 47 binary blobs, 140MB - 127 compiled objects (project code), remainder of the size - A lot of heavy optimisation options, including -Ofast and several unsafe maths optimisations, but also tweaked optimiser params giving the optimiser much higher memory limits and function size growth etc than would be allowed by default. Here's a pastebin of all optimisation flags used: http://pastebin.com/R6dNCMhP - The only difference between the tests was disabling -fuse-linker-plugin and -flto for the without-lto build. Both were built from scratch. Comparison results: Without LTO.With LTODifference Build time 20m 51s 28m 2s +34% Object size 152,243,279 bytes 169,512,168 bytes +11% Object size minus blobs 4,977,685 bytes 22,246,874 bytes+346% File size 152,585,216 bytes 150,350,848 bytes -2% File size minus blobs 5,319,622 bytes 3,085,254 bytes -42% Benchmark time 1m 53s 1m 47s -6% This is probably not a very good generalisation for the use of LTO since my use-case is quite specific, but these numbers might be of interest nevertheless. In summary, you're basically paying 34% more compilation time (from scratch - haven't compared partial compiles) and 300% more pre-linked objet size, and in return getting 42% smaller compiled code size and 6% performance improvement. In games, absolutely any measurable performance improvement is worth any amount of extra compile-time cost, but that may not be true for other fields. Regards, Riot On 29 May 2015 at 13:27, Ruben Van Boxem vanboxem.ru...@gmail.com wrote: 2015-05-29 13:36 GMT+02:00 Riot rain.back...@gmail.com: 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 etienne.san...@m4x.org 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
Re: [Mingw-w64-public] [[ noreturn ]]
Thank you, I did not understand the purpose of the attribute, but now it is
clear.
-Original Message-
From: Martin Sebor
Sent: Friday, May 29, 2015 5:21 PM
To: Hotmail (ArbolOne) ; gcc-help Mailing List ; MinGW-64 Mailinglist
Subject: Re: [[ noreturn ]]
On 05/29/2015 03:03 PM, Hotmail (ArbolOne) wrote:
This is the actual code where the test takes place:
void ascii_all [[ noreturn ]] () {
uint32_t ASCII_MAX = 255;
std::wstring a;
for (uint32_t i = 0; i = ASCII_MAX; i++) {
a = i;
size_t w1/*, w2*/;
if ( i 10 ) w1 = 3;
else w1 = 2;
wcout setw( w1 )
a
setw( 6 )
i;
}
wcout L\nThis are the ASCII character from 33 to 255
std::endl;
//wcin.get();
}
The function above returns to its caller so the attribute on
its declaration is incorrect and the warning is justified.
The purpose of the noreturn attribute is to indicate to the
compiler that the function doesn't return to its caller (e.g.,
because it always throws an exception or calls abort or exit).
This is useful because then the compiler can then better
optimize callers to the function.
The C++ attribute noreturn is essentially equivalent to GCC
attribute noreturn:
http://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-functions-that-never-return-3111
Martin
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [[ noreturn ]]
This is the actual code where the test takes place:
void ascii_all [[ noreturn ]] () {
uint32_t ASCII_MAX = 255;
std::wstring a;
for (uint32_t i = 0; i = ASCII_MAX; i++) {
a = i;
size_t w1/*, w2*/;
if ( i 10 ) w1 = 3;
else w1 = 2;
wcout setw( w1 )
a
setw( 6 )
i;
}
wcout L\nThis are the ASCII character from 33 to 255 std::endl;
//wcin.get();
}
--
I downloaded MinGW-w64 from http://sourceforge.net/projects/mingw-w64/
MinGW-w64 settings:
Version 4.9.2 or later
Architecture: x86_64
Threads: win32
Exception: seh
Please let me know if you need anything else.
Thanks a whole bunch for the help, I really appreciated.
-Original Message-
From: Martin Sebor
Sent: Friday, May 29, 2015 12:43 PM
To: Hotmail (ArbolOne) ; gcc-help Mailing List ; MinGW-64 Mailinglist
Subject: Re: [[ noreturn ]]
On 05/28/2015 08:46 PM, Hotmail (ArbolOne) wrote:
Hi!
When using this the [[ noreturn ]] attribute like this: - void f [[
noreturn ]] (); - I get a warning that reads:
warning: 'noreturn' function does return
( http://www.stroustrup.com/C++11FAQ.html#attributes )
What can I do to remove this warning?
I don't see a warning for the example with GCC 4.8, 4.9, or
5.1. If you do, it might help if you posted the version of
GCC you're using and the command line options (for example,
like I did below). You could also check Bugzilla for known
noreturn bugs (though I couldn't find anything relevant).
Martin
$ cat t.cpp g++ -v g++ -Wall -Wextra -c -pedantic -std=c++11 t.cpp
void f [[ noreturn ]] () { throw error; }
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/ppc64-redhat-linux/4.8.3/lto-wrapper
Target: ppc64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap
--enable-shared --enable-threads=posix --enable-checking=release
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-linker-hash-style=gnu
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto
--enable-plugin --enable-initfini-array --disable-libgcj
--with-isl=/builddir/build/BUILD/gcc-4.8.3-20140911/obj-ppc64-redhat-linux/isl-install
--with-cloog=/builddir/build/BUILD/gcc-4.8.3-20140911/obj-ppc64-redhat-linux/cloog-install
--enable-gnu-indirect-function --enable-secureplt --with-long-double-128
--with-cpu-32=power7 --with-tune-32=power7 --with-cpu-64=power7
--with-tune-64=power7 --build=ppc64-redhat-linux
Thread model: posix
gcc version 4.8.3 20140911 (Red Hat 4.8.3-9) (GCC)
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [[ noreturn ]]
On 05/29/2015 03:03 PM, Hotmail (ArbolOne) wrote:
This is the actual code where the test takes place:
void ascii_all [[ noreturn ]] () {
uint32_t ASCII_MAX = 255;
std::wstring a;
for (uint32_t i = 0; i = ASCII_MAX; i++) {
a = i;
size_t w1/*, w2*/;
if ( i 10 ) w1 = 3;
else w1 = 2;
wcout setw( w1 )
a
setw( 6 )
i;
}
wcout L\nThis are the ASCII character from 33 to 255 std::endl;
//wcin.get();
}
The function above returns to its caller so the attribute on
its declaration is incorrect and the warning is justified.
The purpose of the noreturn attribute is to indicate to the
compiler that the function doesn't return to its caller (e.g.,
because it always throws an exception or calls abort or exit).
This is useful because then the compiler can then better
optimize callers to the function.
The C++ attribute noreturn is essentially equivalent to GCC
attribute noreturn:
http://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-functions-that-never-return-3111
Martin
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
