<div dir="ltr">Hi Max and Harald,<br><br>As I mentioned above, my suggestion is to keep the source code<br>"as portable as possible", which doesn't mean absolutely portable.<br>I don't suggest to add other UNIX platforms (Darwin, Solaris, etc.)<br>to our portability scope, I suggest to perform checks on the same<br>platforms as we currently do, but additionally to have both Clang<br>and GCC on both slaves.<br><br>Why Clang?<br><br> - it's default compiler on FreeBSD (recent distributions);<br> - it has its own big community;<br> - it has growing compatibility with GCC, see:<br> <a href="http://en.wikipedia.org/wiki/Clang#Performance_and_GCC_compatibility">en.wikipedia.org/wiki/Clang#Performance_and_GCC_compatibility</a><br><br>Why different versions?<br><br> - different distributions provide different versions available<br> out of the box, i.e. some (such as FreeBSD) provide the latest<br> version, while some other provide a bit dated versions;<br> - some things may change in newer versions, e.g. from my recent<br> experience: Clang 4.0 has support of the __builtin_cpu_supports<br> built-in, while older versions don't.<br><br>I see the only disadvantage of this approach - longer total build<br>time. So, if you guys support this idea, I could do all configuration<br>and installation related work. Also, I'll try to contribute some<br>computing power to Jenkins: there are some servers in my university,<br>which power isn't used anyhow, so they mostly idle all the time.<br><br>> Recently I decided to dig into FreeBSD's world, because one of my<br>> changes in Gerrit does build fine on Debian slave, but doesn't on<br>> FreeBSD.<br><br>Here I found the problem. Cite from GCC's documentation page<br>x86-Built-in-Functions.html at <a href="http://gcc.gnu.org">gcc.gnu.org</a>:<br><br>> If you specify command-line switches such as -msse, the compiler<br>> could use the extended instruction sets even if the built-ins<br>> are not used explicitly in the program. For this reason, applications<br>> that perform run-time CPU detection must compile separate files for<br>> each supported architecture, using the appropriate flags. In<br>> particular, the file containing the CPU detection code should be<br>> compiled without these options.<br><br>Adding SIMD flags to a whole project breaks portability between<br>different CPUs, so I added these flags for viterbi_sse.lo only.<br>Now the problem seems solved.<br><br><br clear="all"><div><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>With best regards,<br></div><div>Vadim Yanitskiy.<br></div></div></div></div></div></div>
</div></div>