[R-SIG-Win] Windows toolchain update: seh vs sjlj

[Avraham Adler]

On Sun, Sep 13, 2015 at 12:36 PM, Jeroen Ooms <jeroen.ooms at stat.ucla.edu> wrote:
> Hi all,
>
> The good news: the mingw-w64 authors suggest to move away from the
> SJLJ exception model, and instead use DWARF on win32 and SEH on win64.
> These exception models are the default in mingw-w64 since gcc 4.8
> because they are more reliable and performant. So we built a copy of
> i686-493-posix-dwarf-rt_v3-s and x86_64-493-posix-seh-rt_v3-s and used
> this to compile R. The results are quite amazing: both R and Rcpp pass
> all their checks without any special compiler flags (even without
> --no-asynchronous-unwind-tables). So far I have not been able to
> reproduce a single problem case with this new build, and it is
> noticeably faster as well. This confirms the sentiment of the
> mingw-w64 authors that SJLJ does not play nice with recent features of
> gcc.


Just an update on some testing. I've built R-devel_2015-09-10 on an
i7-3740QM @ 2.7Ghz with 8MB RAM running Windows7 64bit under the new
toolchain (4.9.3-SEH-POSIX) with the following permutations:

* vanilla (outside of -mtune=generic)
* With OpenBLAS
* With OpenBLAS and -mtune=native
* With OpenBLAS and -march=native
* With OpenBLAS and link-time-optimization and -mtune=native
* With OpenBLAS and link-time-optimization and -march=native

Each time it passes make check-devel + make check-recommended (with
the last, I haven't finished make check-devel as at work, I'm behind a
firewall and the Internet2 test dies, preventing everything from
segfault and on)

I also build the 80-some packages I usually from source, and the only
issues I've found so far is that 1) 'dplyr' doesn't compile well when
specifying C++11 (either as c++111 or gnu++11) but compiles fine
without it, 2) when using link-time-optimization, even though
'stringi' compiles from source, it causes a crash when 'knitr' is
being installed. Installing 'stringi' as a binary (which is much
faster than building it) obviates that problem, and 3) I'm having
trouble with running 'rstan' (although it compiles as long as no C++11
option is passed) which I will bring to the attention of the rstan
developers.

I have not run the Rcpp segfault test as I always have problems with
devtools, but you've said you're satisfied with that. Maybe over the
weekend I can run some timing tests for comparison.

Are there any tests in specific which would be useful?

Avi