Re: [lmi] Upgrade gcc now?

[Vadim Zeitlin]

On Tue, 9 May 2017 17:57:05 +0000 Greg Chicares <address@hidden> wrote:

GC> Right now Kim and I both use gcc-4.9.x . She can pick any version that
GC> the MinGW-w64 project has released:
GC>   https://sourceforge.net/projects/mingw-w64/files/mingw-w64/
GC> 7.1, 6.3, 6.2, and 5.4 seem to be the likely candidates. So far, I've
GC> been using only debian packages, and if I stay on that track I could
GC> create a debian-testing chroot with 6.3.0 (same gcc version as for
GC> debian unstable today). Alternatively, I could try using a package
GC> from MinGW-w64 directly, which might or might not be easy, so that
GC> leads me to my first question: do you think 7.1 is so much better
GC> than 6.3 that I should try to do this?

 Hello,

 The main difference between gcc 7 and 6 is that the newer version has full
C++17 support, including "if constexpr" (which we already regretted not
having in bourn_cast.hpp) and structured bindings which, together with the
support for initializers in "if" and "switch" statements should allow
writing shorter and more expressive code (but I don't really have any
experience using them just yet). There are, of course, plenty of other
nice-to-have things in C++17, e.g. static_assert() without an explicit
message or template argument deduction for class templates. At the library
level, std::variant<> and std::optional<> are very nice to have too IMHO.

 For reference, I think http://stackoverflow.com/a/38060437/15275 describes
all the new features in a nicely condensed, yet sufficiently clear, form.
AFAIK gcc 7 supports all of them.

 In conclusion, I think it would be absolutely worth using gcc 7 if
possible, "just" for C++17 and forgetting about the supposed improvements
to its optimizer and the bug fixes.


GC> Here's my other question: which flavor(s) should we plan to use? If
GC> we're going to upgrade anyway, we may as well fetch both i686 and
GC> x86_64 versions: I'm pretty sure nobody is running lmi on a 32-bit OS
GC> any more, so we should experiment with a 64-bit build.

 Yes, definitely. If nothing else, it would be interesting to compare its
performance with 32 bit build.

GC> The question then comes down to: which exception models? For i686, I
GC> suppose sjlj is still the only one we can expect to work, because we
GC> need to throw exceptions across the DLL and kernel boundaries. But for
GC> x86_64, will seh avoid that problem, or will we still need sjlj?
GC> 
GC> IOW, of the files offered here:
GC>   https://sourceforge.net/projects/mingw-w64/files/mingw-w64/
GC> today we're using
GC>   i686-4.9.1-release-win32-sjlj-rt_v3-rev3.7z
GC> but for 6.3.0 I think we want
GC>   i686-6.3.0-release-win32-sjlj-rt_v5-rev1.7z
GC> and one of these two
GC>   x86_64-6.3.0-release-win32-sjlj-rt_v5-rev1.7z
GC>   x86_64-6.3.0-release-win32-seh-rt_v5-rev1.7z
GC> where AFAICT "win32" selects msw rather than posix threads.

 I have to admit that I don't actually have any experience with MinGW SEH
64 bit version, but, assuming it works (and I think it does, at least I
didn't find any mentions of any fatal problems with it after a quick web
search), it's definitely preferable to SJLJ hack. It should be more
efficient both when throwing and, more importantly, when not throwing,
exceptions and also generate smaller code. SEH is the way exceptions are
supposed to work under the MSW platform.

 Regards,
VZ