Test one compiler per OS

[seantalts]

Note

Pull request #944 only addresses part of this issue / proposal:

• mac / clang 6 / libc++ Threading unit tests
• linux / gcc 5 / stdlibc++ OpenMPI unit tests
• mac clang 6 libc++ OR linux clang 6 libc++[2] distribution tests (without row vectors)

Additional tests on merge to develop linux / gcc 5 / stdlibc++ Threading unit tests mac / clang 6 libc++ OR linux / gcc 5 stdlibc++[1] GPU unit tests mac clang 6 libc++ OR linux clang 6 stdlibc++[2] distribution tests (with row vectors)

• It does not address testing the header tests on mac + linux + windows.
• It does not address testing on Windows.

Summary:

As we discussed in the meeting on July 12th and in this discourse thread, we'd like to change our CI configuration to test just one per OS.

Description:

Here are the proposed supported compilers for each OS: Mac: clang 5 Linux: clang 5 (maybe a gcc - TBD) Windows: gcc 4.9.3

For tests, these are the tests that should be tested on each of those configurations:

1. header tests. make test-headers
2. unit tests. ./runTests.py test/unit
3. distribution tests. ./runTests.py test/prob

These tests only need to be run on one platform since they're not compiler dependent:

1. CppLint. make cpplint
2. Math dependencies (checks the source to make sure it's not including headers in a bad way). make test-math-dependencies
3. Building doxygen. make doxygen

From what I understand, inter-clang compatibility is pretty high, while GCC is needed for Windows RTools (until they switch to a modern GCC in April 2019). GCC had major changes across the 5.0 boundaries, but I think testing both modern ish non-Apple clang and old-ish GCC will still keep our code supported by the compilers basically all of our existing users have access to.

This ticket will involve changing the travis and Jenkins config (and for Jenkins agents, the installed software) to test the above compilers.

Once this is in, we should update the wiki page here: https://github.com/stan-dev/stan/wiki/Supported-C---Compilers-and-Language-Features

cc @bgoodri @syclik @bob-carpenter

Current Version:

v2.18.0

[bgoodri]

g++ is much more commonly used on Linux than clang++

On Mon, Jul 16, 2018 at 9:37 AM seantalts notifications@github.com wrote:

Summary:

As we discussed in the meeting on July 12th, we'd like to change our supported compilers to support (and test!) just one per OS. Description:

Here are the proposed supported compilers for each OS: Mac: clang 6.0 https://cran.r-project.org/bin/macosx/tools/ Linux: clang 6.0 Windows: gcc 4.9.3 https://cran.r-project.org/bin/windows/Rtools/

From what I understand, inter-clang compatibility is pretty high, while GCC is needed for Windows RTools (until they switch to a modern GCC in April 2019). GCC had major changes across the 5.0 boundaries, but I think testing both modern ish non-Apple clang and old-ish GCC will still keep our code supported by the compilers basically all of our existing users have access to.

This ticket will involve changing the travis and Jenkins config (and for Jenkins agents, the installed software) to test the above compilers.

Once this is in, we should update the wiki page here: https://github.com/stan-dev/stan/wiki/Supported-C---Compilers-and-Language-Features

cc @bgoodri https://github.com/bgoodri @syclik https://github.com/syclik @bob-carpenter https://github.com/bob-carpenter Current Version:

v2.18.0

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/stan-dev/math/issues/943, or mute the thread https://github.com/notifications/unsubscribe-auth/ADOrqhBYyIeTSoIgCvPCA0SxoS5kjXyJks5uHJcZgaJpZM4VRJGI .

[seantalts]

I like clang for Linux because:

1. It's much faster and more memory efficient (meaning we can run a higher -jX and tests will run faster). This saves the project actual dollars.
2. clang seems like the future - has many more companies backing it and generally seems like it has a steeper trajectory
3. clang has better static analysis tooling
4. I don't think stats exist describing our Linux users compiler availability. I'm saying availability here because we don't necessarily care if our code somehow doesn't compile on Linux gcc despite it compiling for Windows gcc and the user is able to easily install clang and have things work. To make the tradeoff explicit, we need to resize our support commitments to fit the person-hours of those working on things like these at the expense of a low chance of making some Linux users install an extra package.

[bgoodri]

In the early days of Stan, clang++ was much faster to compile and used less RAM. That is much less true today as clang++ has taken more time and RAM in order to improve execution speed. The static analysis thing is nice but you can get that on a Mac or just by running it occasionally on Linux. That doesn't have much to do with whether unit tests pass or models run much more slowly.

But my main point is that if you are going to only test one compiler per OS, it should be the one that you anticipate being used the most, which is gcc on Linux by orders of magnitude

On Mon, Jul 16, 2018 at 10:57 AM seantalts notifications@github.com wrote:

I like clang for Linux because:

1. It's much faster and more memory efficient (meaning we can run a higher -jX and tests will run faster). This saves the project actual dollars.
2. clang seems like the future - has many more companies backing it and generally seems like it has a steeper trajectory
3. clang has better static analysis tooling
4. I don't think stats exist describing our Linux users compiler availability. I'm saying availability here because we don't necessarily care if our code somehow doesn't compile on Linux gcc despite it compiling for Windows gcc and the user is able to easily install clang and have things work. To make the tradeoff explicit, we need to resize our support commitments to fit the person-hours of those working on things like these.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/stan-dev/math/issues/943#issuecomment-405276135, or mute the thread https://github.com/notifications/unsubscribe-auth/ADOrqhKKmpghHdFgP1hWR2L1KuCuesNMks5uHKnmgaJpZM4VRJGI .

[bbbales2]

Yeah clang is nice and all, but it performs about the same as gcc for me (edit: agreeing with other Ben here). I think gcc does a better job of flagging code with warnings (int/size_t comparisons etc.) in terms of minor arguments for/against. I definitely think both should be tested. If it's only one, then I agree gcc is the one.

[seantalts]

@bbbales2 can you provide some reasoning? Why should both compilers be tested on Linux given what I wrote above?

I can try out a modern GCC (which version?) and see how long the distribution tests take. I know gcc-4.9.3 is at least twice as slow as clang-3.8 but I suppose you might be referring to those versions as "the early days"

[bgoodri]

The early days were actually g++-4.6, which didn't support C++11.

On Mon, Jul 16, 2018 at 11:37 AM seantalts notifications@github.com wrote:

@bbbales2 https://github.com/bbbales2 can you provide some reasoning? Why should both compilers be tested on Linux given what I wrote above?

I can try out a modern GCC (which version) and see how long the distribution tests take. I know gcc-4.9.3 is at least twice as slow as clang-3.8 but I suppose you might be referring to those versions as "the early days"

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/stan-dev/math/issues/943#issuecomment-405289600, or mute the thread https://github.com/notifications/unsubscribe-auth/ADOrqu8NOWk3ousnrJWriupB3H5L_GISks5uHLNTgaJpZM4VRJGI .

[bob-carpenter]

I've found warnings keep leapfrogging one another in g++ and clang++. I use both if I can't sort something out.

clang++ used to be a lot faster, but now I'm finding my models take forever to compile on the Mac. We really really need to address the compilation time problem if the compilers are going to keep going crazy with compilation time.

On Jul 16, 2018, at 5:22 PM, Ben Bales notifications@github.com wrote:

Yeah clang is nice and all, but it performs about the same as gcc for me. I think gcc does a better job of flagging code with warnings (int/size_t comparisons etc.) in terms of minor arguments for/against. I definitely think both should be tested. If it's only one, then I agree gcc is the one.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[seantalts]

One reason I'm particularly fond of matching the compiler on Mac and Linux is because those users are usually pretty flexible and we generally want to avoid giving too many compilation targets for developers or it will start to approach front-end developer's dreaded cross-browser compatibility matrices. This gives me a strong bias towards selecting the same compiler for both, and given most of our users are on RStudio on Mac (which needs clang to link) and the Chrome team's recent writeup of clang vs. gcc I'm still very biased towards only testing Clang for Linux in CI, even if it means we need to ask some Linux users to install an extra package (under what would be pretty weird circumstances).

Running the performance numbers for distribution tests on gcc vs clang for Linux would help convince me otherwise, though. Anyone know what version I should target? I can't (quickly) find the docs that describe what RStudio is usually built with for Linux.

[bgoodri]

We don't have the conference bodyguard budget to tell Linux people "just install clang-6.0".

For unit testing, it seems obvious to me that you want diversity of compilers rather than homogeneity.

Also, it is fine to say that we only have the resources to test a finite set of things, but it is wrong to suggest that we are not going to fix compiler issues for compilers that we do not test. We are already responsible for 12 OS / compiler combinations for each R package and there are a few more with PyStan where we have to fix things when they go wrong. It is just a matter of how many things we catch before they get to users.

On Mon, Jul 16, 2018 at 11:54 AM seantalts notifications@github.com wrote:

One reason I'm particularly fond of matching the compiler on Mac and Linux is because those users are usually pretty flexible and we generally want to avoid giving too many compilation targets for developers or it will start to approach front-end developer's dreaded cross-browser compatibility matrices. This gives me a strong bias towards selecting the same compiler for both, and given most of our users are on RStudio on Mac (which needs clang to link) and the Chrome team's recent writeup of clang vs. gcc http://blog.llvm.org/2018/03/clang-is-now-used-to-build-chrome-for.html I'm still very biased towards only testing Clang for Linux in CI, even if it means we need to ask some Linux users to install an extra package.

Running the performance numbers for distribution tests on gcc vs clang for Linux would help convince me otherwise, though. Anyone know what version I should target? I can't (quickly) find the docs that describe what RStudio is usually built with for Linux.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/stan-dev/math/issues/943#issuecomment-405295217, or mute the thread https://github.com/notifications/unsubscribe-auth/ADOrqsbKVdLH-ixDnhHTPHhnDcGolGv-ks5uHLdEgaJpZM4VRJGI .

[seantalts]

We don't have the conference bodyguard budget to tell Linux people "just install clang-6.0".

If you think we don't have resources to do that, wait until you see how many people are willing to work on build / CI / cross-compiler compatibility issues.

More seriously, this is actually a resource question. We don't have almost anyone willing (/able) to work on this stuff, especially not on the CI and build system side of things. Agreed that in a perfect world we'd support every possible thing for every possible person, but we're in the situation now where we're making difficult choices.

To illustrate, @ChrisChiasson has been absolutely heroic in trying to support all of the compilers and toolchains combinations we claim to support, but most people drop out at that point.

If you're willing to find someone to take over (or at least share) this burden with me, I'd say we should go for a diversity of compilers as you suggest. Or if you can show me that GCC is at least as fast and is not actually producing mostly spurious warnings as the Chrome team suggests in the post linked above.

[seantalts]

Speaking of, what version of GCC do you think the RStudio people will switch R to in April 2019? That would be a good one to test against on Linux if it's as fast as clang now.

[bgoodri]

I don't see the relevance of RStudio. Most people install the binaries, which are built with various compiler versions. Moreover, RStudio is a webserver that has little to do with what compiler people would be using to compile Stan models.

On Mon, Jul 16, 2018 at 12:22 PM seantalts notifications@github.com wrote:

Speaking of, what version do you think the RStudio people will switch R to in April 2019? That would be a good one to test against on Linux if it's as fast as clang now.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/stan-dev/math/issues/943#issuecomment-405304150, or mute the thread https://github.com/notifications/unsubscribe-auth/ADOrqqlmUVHsotraZKcsyPHBN5jgVhq4ks5uHL3UgaJpZM4VRJGI .

[seantalts]

Sorry, I was super unclear. I was referring to RStudio switching the compiler on Windows to modern GCC in April 2019. If they're aiming for gcc version 7, then it would be reasonable for us to test gcc version 7 on Linux starting now (assuming it takes about as long as clang to run tests) and then when they finally do switch, we'll be down to just two compiler versions across our 3 OSes.

[bgoodri]

Oh. I think it will be gcc-7 or gcc-8. I don't know if it has been decided yet.

On Mon, Jul 16, 2018 at 12:29 PM seantalts notifications@github.com wrote:

Sorry, I was super unclear. I was referring to RStudio switching the compiler on Windows to modern GCC in April 2019. If they're aiming for gcc version 7, then it would be reasonable for us to test gcc version 7 on Linux starting now (assuming it takes about as long as clang to run tests) and then when they finally do switch, we'll be down to just two compiler versions across our 3 OSes.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/stan-dev/math/issues/943#issuecomment-405305988, or mute the thread https://github.com/notifications/unsubscribe-auth/ADOrqlfvoYIPnrqJjeMolIxQnlFnobGNks5uHL9MgaJpZM4VRJGI .

[seantalts]

Gotcha. So I tried gcc-7 on your Linux box:

g++-7 -Wall -I . -isystem lib/eigen_3.3.3 -isystem lib/boost_1.66.0 -isystem lib/sundials_3.1.0/include -std=c++1y -DB
OOST_RESULT_OF_USE_TR1 -DBOOST_NO_DECLTYPE -DBOOST_DISABLE_ASSERTS -DBOOST_PHOENIX_NO_VARIADIC_EXPRESSION -Wno-unused-
function -Wno-uninitialized -Werror -pthread -DGTEST_USE_OWN_TR1_TUPLE -DGTEST_HAS_PTHREAD=0 -isystem lib/gtest_1.7.0/
include -isystem lib/gtest_1.7.0 -O3 -DNO_FPRINTF_OUTPUT -pipe   -o test/unit/math/prim/scal/fun/inc_beta_ddb_test tes
t/unit/math/prim/scal/fun/inc_beta_ddb_test.o lib/gtest_1.7.0/src/gtest_main.cc lib/gtest_1.7.0/src/gtest-all.o  
test/unit/math/prim/scal/fun/lgamma_test.cpp:15:1: internal compiler error: in fold_convert_loc, at fold-const.c:2262
 }
 ^
0x896897 fold_convert_loc(unsigned int, tree_node*, tree_node*)
        ../../src/gcc/fold-const.c:2261
0x895051 fold_unary_loc(unsigned int, tree_code, tree_node*, tree_node*)
        ../../src/gcc/fold-const.c:7621
0x896079 fold_build1_stat_loc(unsigned int, tree_code, tree_node*, tree_node*)
        ../../src/gcc/fold-const.c:12253
0xe4130d generic_simplify_MINUS_EXPR
        /build/gcc-7-7AsJUH/gcc-7-7.2.0/build/gcc/generic-match.c:13917
0xe61d1d generic_simplify(unsigned int, tree_code, tree_node*, tree_node*, tree_node*)
        /build/gcc-7-7AsJUH/gcc-7-7.2.0/build/gcc/generic-match.c:33857
0x88d2b5 fold_binary_loc(unsigned int, tree_code, tree_node*, tree_node*, tree_node*)
        ../../src/gcc/fold-const.c:9166
0x1128f3f ipa_get_jf_pass_through_result
        ../../src/gcc/ipa-cp.c:1238
0x112deae propagate_vals_across_pass_through
        ../../src/gcc/ipa-cp.c:1576
0x112deae propagate_scalar_across_jump_function
        ../../src/gcc/ipa-cp.c:1656
0x112deae propagate_constants_across_call
        ../../src/gcc/ipa-cp.c:2273
0x1130810 propagate_constants_topo
        ../../src/gcc/ipa-cp.c:3177
0x1130810 ipcp_propagate_stage
        ../../src/gcc/ipa-cp.c:3274
0x1132c87 ipcp_driver
        ../../src/gcc/ipa-cp.c:5002
0x1132c87 execute
        ../../src/gcc/ipa-cp.c:5096
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <file:///usr/share/doc/gcc-7/README.Bugs> for instructions.
<builtin>: recipe for target 'test/unit/math/prim/scal/fun/lgamma_test.o' failed
make: *** [test/unit/math/prim/scal/fun/lgamma_test.o] Error 1

Presumably we should fix that at some point, but probably only after the R switch in April and only if they choose gcc-7.

[bgoodri]

I haven't been able to replicate that error. Did you just do ./runTests.py test/unit/math/prim/scal/fun/inc_beta_ddb_test.cpp ?

But, more to the point, we can't say "Here is a known bug, we'll fix it in about a year." The latest stable gcc is gcc-8, gcc-7 has been released since May of last year, and gcc-7 is the default compiler for the latest Ubuntu long-term support release (Bionic Beaver). We have to take responsibility for bugs that we know about even if we don't search that exhaustively for them.

On Mon, Jul 16, 2018 at 12:37 PM seantalts notifications@github.com wrote:

Gotcha. So I tried gcc-7 on your Linux box:

g++-7 -Wall -I . -isystem lib/eigen_3.3.3 -isystem lib/boost_1.66.0 -isystem lib/sundials_3.1.0/include -std=c++1y -DB OOST_RESULT_OF_USE_TR1 -DBOOST_NO_DECLTYPE -DBOOST_DISABLE_ASSERTS -DBOOST_PHOENIX_NO_VARIADIC_EXPRESSION -Wno-unused- function -Wno-uninitialized -Werror -pthread -DGTEST_USE_OWN_TR1_TUPLE -DGTEST_HAS_PTHREAD=0 -isystem lib/gtest_1.7.0/ include -isystem lib/gtest_1.7.0 -O3 -DNO_FPRINTF_OUTPUT -pipe -o test/unit/math/prim/scal/fun/inc_beta_ddb_test tes t/unit/math/prim/scal/fun/inc_beta_ddb_test.o lib/gtest_1.7.0/src/gtest_main.cc lib/gtest_1.7.0/src/gtest-all.o test/unit/math/prim/scal/fun/lgamma_test.cpp:15:1: internal compiler error: in fold_convert_loc, at fold-const.c:2262 } ^ 0x896897 fold_convert_loc(unsigned int, tree_node, tree_node) ../../src/gcc/fold-const.c:2261 0x895051 fold_unary_loc(unsigned int, tree_code, tree_node, tree_node) ../../src/gcc/fold-const.c:7621 0x896079 fold_build1_stat_loc(unsigned int, tree_code, tree_node, tree_node) ../../src/gcc/fold-const.c:12253 0xe4130d generic_simplify_MINUS_EXPR /build/gcc-7-7AsJUH/gcc-7-7.2.0/build/gcc/generic-match.c:13917 0xe61d1d generic_simplify(unsigned int, tree_code, tree_node, tree_node, tree_node) /build/gcc-7-7AsJUH/gcc-7-7.2.0/build/gcc/generic-match.c:33857 0x88d2b5 fold_binary_loc(unsigned int, tree_code, tree_node, tree_node, tree_node) ../../src/gcc/fold-const.c:9166 0x1128f3f ipa_get_jf_pass_through_result ../../src/gcc/ipa-cp.c:1238 0x112deae propagate_vals_across_pass_through ../../src/gcc/ipa-cp.c:1576 0x112deae propagate_scalar_across_jump_function ../../src/gcc/ipa-cp.c:1656 0x112deae propagate_constants_across_call ../../src/gcc/ipa-cp.c:2273 0x1130810 propagate_constants_topo ../../src/gcc/ipa-cp.c:3177 0x1130810 ipcp_propagate_stage ../../src/gcc/ipa-cp.c:3274 0x1132c87 ipcp_driver ../../src/gcc/ipa-cp.c:5002 0x1132c87 execute ../../src/gcc/ipa-cp.c:5096 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See file:///usr/share/doc/gcc-7/README.Bugs for instructions.

: recipe for target 'test/unit/math/prim/scal/fun/lgamma_test.o' failed make: *** [test/unit/math/prim/scal/fun/lgamma_test.o] Error 1 Presumably we should fix that at some point, but perhaps after the R switch in April. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub , or mute the thread .

[seantalts]

Maybe my checkout was in a bad state - cleared it and trying again.

Chris, I am opposed to it for the reasons above.

[seantalts]

Okay, that error happened again. I ran ./runTests.py -j12 test/unit and it popped up a few minutes in.

I disagree with the stance that we have to support GCC-7 on Linux for those reasons - that's the ideal, sure, but I think we need to choose what the core Stan dev team will take responsibility for and test on our CI. Happy to review PRs addressing compiler bugs but I don't think we need to be preemptively fixing every cross compiler bug ourselves before anyone needs it, as this gcc-7 bug might seem to indicate.

[bgoodri]

The fact that it does not occur when you do

make clean-all ./runTests.py test/unit/math/prim/scal/fun/inc_beta_ddb_test.cpp

suggests that, if anything, it is a bug in Stan's test framework rather than the g++-7 compiler.

But that is beside the point. No one is saying that we have to test as many compilers as Boost (or CRAN), which are listed at the end of

https://www.boost.org/users/history/version_1_67_0.html

But I am saying it is completely irresponsible to not fix bugs that we are aware of with recent releases of open source compilers. It is fine to say g++-4.8 and older are not supported because Stan requires compliance with the C++14 standard. You can kind of get away with saying g++-9 is not released yet, so we are not going to worry about issues with it until there is a beta release. You cannot say things like everyone using the latest Ubuntu LTS release can either install a non-default compiler or not use Stan.

On Mon, Jul 16, 2018 at 1:08 PM seantalts notifications@github.com wrote:

Okay, that error happened again. I ran ./runTests.py -j12 test/unit and it popped up a few minutes in.

I disagree with the stance that we have to support GCC-7 on Linux for those reasons - that's the ideal, sure, but I think we can choose what the core Stan dev team will take responsibility for and test on our CI. Happy to review PRs addressing compiler bugs but I don't think we need to be preemptively fixing every cross compiler bug ourselves before anyone needs it, as this gcc-7 bug might seem to indicate.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/stan-dev/math/issues/943#issuecomment-405317987, or mute the thread https://github.com/notifications/unsubscribe-auth/ADOrqucqSysfW6CdwR51nVcMr3qhR4S5ks5uHMidgaJpZM4VRJGI .

[seantalts]

You're running the wrong test: ./runTests.py test/unit/math/prim/scal/fun/lgamma_test.cpp also crashes.

I understand what you are saying your position is but I do not know the reasoning yet. Why cannot we say things like "Everyone using the latest Ubuntu LTS release can either install a non-default compiler or not use Stan (we accept PRs to fix this)?" For example, the latest Ubuntu LTS does not come with any compiler. So they already need to install a non-default package. Why don't we specify which one?

[bob-carpenter]

On Jul 16, 2018, at 6:02 PM, bgoodri notifications@github.com wrote:

We don't have the conference bodyguard budget to tell Linux people "just install clang-6.0".

Is that because it's hard to install clang 6 on Linux?

For unit testing, it seems obvious to me that you want diversity of compilers rather than homogeneity.

Why? The problem is not only our code not being standards compliant, the problem is that we've had to code around standards failures on bunches of them. It really slows down C++ development, which is what we're trying to get unstuck.

Also, it is fine to say that we only have the resources to test a finite set of things, but it is wrong to suggest that we are not going to fix compiler issues for compilers that we do not test. We are already responsible for 12 OS / compiler combinations for each R package and there are a few more with PyStan where we have to fix things when they go wrong. It is just a matter of how many things we catch before they get to users.

Is there a list of those somewhere?

RStan also requires us to match Boost versions with BH and Eigen versions with RcppEigen.

On Jul 16, 2018, at 6:22 PM, seantalts notifications@github.com wrote:

Speaking of, what version do you think the RStudio people will switch R to in April 2019? That would be a good one to test against on Linux if it's as fast as clang now.

Isn't RStudio going to just follow Rtools?

It sounded like Rstudio was going to pre-install the dev tools.

Do most of our R users use RStudio?

On Jul 16, 2018, at 6:55 PM, bgoodri notifications@github.com wrote:

We have to take responsibility for bugs that we know about even if we don't search that exhaustively for them.

I don't see why. Sure, all else being equal, that'd be great.

The problem is that we're getting bogged down in compiler variants.

I suppose the other option is to just cut down on our use of modern C++ features and stick mainly to simple, less templated, non-C++11 stuff that's supported pretty much everywhere. Then we're less likely to get bogged down in compiler incompatibilities.

P.S. This should be a Discourse discussion, as it doesn't seem ready for an issue.

[sakrejda]

The issue with requiring clang on Linux is that Ubuntu's clang package is.. odd.., for example I have only been able to get it to work with the standard c++ lib not the clang c++ lib

[bgoodri]

It isn't hard to install clang on Linux if you have root access. But in a lot of situations with Linux servers users don't. Even the sys-admins are constrained by what is covered by their support contracts.

Moreover, I don't know of a single open-source projects that has a policy of "we only address problems with clang, not gcc". If anything, there might be the opposite, but most projects fixed bugs involving both gcc and clang --- even when clang had very few users --- because it is the right thing to do as a member of the open source community and because it makes both projects stronger. Stan wouldn't be where it is today without the efforts of the gcc developers and I am astonished that we would even consider WONTFIXING issues that come up with gcc.

Even if we did, do you think we would magically get an exception from CRAN's policies? They have tens of thousands of packages to deal with and test and they rightfully expect that package maintainers fix issues that are revealed by these operating systems and compilers, including several versions of clang and gcc,

https://cran.r-project.org/web/checks/check_flavors.html

which evolves every few months.

Do you think we would also magically get an exception from Debian's policies once Stan gets out of the NEW queue? That is going to entail working with the Debian maintainers to sort out bugs on hardware that isn't even Intel

https://buildd.debian.org/status/package.php?p=r-base

plus making the Sundials and manuals builds bitwise reproducible within compilers.

Stan has more full-time developers and probably more funding than Eigen, which manages to test under

http://manao.inria.fr/CDash/index.php?project=Eigen

Of course, Eigen is used in a lot more projects than Stan is and benefits from whatever tests those projects are conducting. But Eigen wouldn't benefit nearly as much if it only fixed bugs on one compiler per OS.

[sakrejda]

Btw, for the systems I use I'm willing to resolve bugs for the standard compilers. That's usually the latest Ubuntu LTS, the latest Ubuntu non-LTS, and (currently) arch (which despite being weird actually gives me the fewest problems, it's on gcc-8...)

[seantalts]

@sakrejda Well there's a bug above in gcc-7 where gcc had a regression and started crashing from C++ code that worked on earlier versions of gcc and all versions of clang, if you want something to look at :P

I am opening a discourse issue here: http://discourse.mc-stan.org/t/one-compiler-per-os/4899

[seantalts]

(and @bgoodri, I tried to clear this up in the discourse post, but no one is proposing WONTFIXING anything - just not testing against these compilers and not obligating anyone in particular at Columbia to fix issues that do arise)

[bgoodri]

That policy is pretty close to WONTFIXING, unlike any policy of other open-source projects besides things like FreeBSD, and one that I would think a lot of unpaid people who are working to spread Stan to a wider audience would be disgusted by.

On Tue, Jul 17, 2018 at 11:41 AM seantalts notifications@github.com wrote:

(and @bgoodri https://github.com/bgoodri, I tried to clear this up in the discourse post, but no one is proposing WONTFIXING anything - just not testing against these compilers and not obligating anyone in particular at Columbia to fix issues that do arise)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/stan-dev/math/issues/943#issuecomment-405628407, or mute the thread https://github.com/notifications/unsubscribe-auth/ADOrqqNDNN6OGR8Ve8Q8O4EGhTPVCbt1ks5uHgWqgaJpZM4VRJGI .

[seantalts]

Would you mind presenting your counter proposal on the discourse post?

[sakrejda]

@seantalts, which Ubuntu is that gcc-7 running?

[bgoodri]

Xenial (but we may need to upgrade soon to get the GPU stuff to work reliably). g++-7 (Ubuntu 7.2.0-1ubuntu1~16.04) 7.2.0

On Tue, Jul 17, 2018 at 2:53 PM Krzysztof Sakrejda notifications@github.com wrote:

@seantalts https://github.com/seantalts, which Ubuntu is that gcc-7 running?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/stan-dev/math/issues/943#issuecomment-405689626, or mute the thread https://github.com/notifications/unsubscribe-auth/ADOrqj-R-FM0J8H0V4FZ-Df7WVUm973jks5uHjKvgaJpZM4VRJGI .

[sakrejda]

I'll have access to that tomorrow , I'll check it out