On Fri, 24 Mar 2017 at 06:43 Antoine Pitrou antoine@python.org wrote:
Hello,
I am curious about the decision to have Travis-CI tests with both clang and gcc.
It was when I was trying to maximize Travis usefulness before the migration. It's also because we as a project have found bugs in both compilers previously (I know I personally reported a bug that affected both of them once upstream).
clang is a compiler which strives to be very compatible with gcc. I would understand testing under OS X with clang in addition to Linux with gcc, but I'm skeptical we gain much from testing both gcc and clang under Linux. Also, it lengthens CI times, as clang produces slower code in debug mode than gcc does (because we use "-Og" on gcc).
Is there an equivalent flag for clang we should be using?
Or perhaps we could switch the clang build to produce a non-debug interpreter (and therefore a faster test suite)?
Another option is if we drop a compiler from a debug build we can use it for the coverage run so it's at least being exercised somewhere.
If we drop either compiler I would vote for dropping gcc actually as the compiler messages are much worse on gcc compared to clang. I guess it comes down to whether we think CI should be used as a fallback for a failing test suite or if we think CI might help contributors if they happen to have a bug in their C code that they simply didn't notice (e.g. thought they made an innocuous fix that didn't warrant a rebuild).