<br><br>On Friday, January 8, 2016, Jason Gunthorpe <<a href="mailto:jgunthorpe@obsidianresearch.com">jgunthorpe@obsidianresearch.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Jan 08, 2016 at 02:48:47PM -0800, Jeff Hammond wrote:<br>
>    It's not a huge swath of cases.  It is a very large number of instances<br>
>    of a very small number of cases.  I suspect that your huge swatch of<br>
>    cases boils down to {Linux,BSD} x<br>
>    {x86(_64),ppc{32,64,64le},arm{32,64}}.  I guess there might be a mips<br>
>    or a sparc in there, but what you are really saying here is that you<br>
>    think two instantiations of POSIX represent the entirety of computing.<br>
<br>
? gcc runs on almost everything, and generally isn't hard to<br>
install. Solaris, Windows, AIX, Mac OS, no problems. Most common cases<br>
have recent binary builds available.<br>
<br></blockquote><div><br></div>According to knowledgable third parties, it is not available on the Fujitsu K machine.<div><br></div><div>The version of GCC supported on Blue Gene/Q is 4.8. <br><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
>    You're right.  libfabric should use as many features from C11 as<br>
>    possible and expect everyone whose machine doesn't have GCC 5.3 and<br>
>    Clang 3.8 on it to build their C compiler toolchain from source.<br>
<br>
I wouldn't be that extreme.<br>
<br>
C11 support requires gcc 4.9 for full compiler features (yes, I know<br>
the library side is missing) and that is now nearly a two<br>
year old compiler.</blockquote><div><br></div><div>Does GCC 4.9 support atomics? I don't have a binary handy...</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
If it makes sense I wouldn't shy away from C11 features, many are very<br>
handy. And I wouldn't do a Windows port without a C11 compatible<br>
compiler.</blockquote><div><br></div><div>I don't know that the group will go for anything past C99, but we should try to enumerate the list of C11 features we would use if it were permitted. </div><div><br></div><div>Of course, provider code can assume far more. The Cray provider uses C11 atomics...</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
>    Let's make life miserable on everyone running Debian stable,<br>
>    CentOS 6.x, etc.<br>
<br>
CentOS 6 & 7 have RH supported packages for gcc 4.9 available via yum.<br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Debian stable already ships gcc 4.9<br>
<br>
A binary install is avaiable for Mac OS<br>
<br>
A binary is avaiable for Windows.<br>
<br>
Clang 3.7 equally supports C11, and provides binaries for windows and<br>
x86 linux.<br>
<br>
Don't overstate how hard the typical case is.<br>
<br>
Yes, the atypical case could be very hard, but<br>
<br>
>      The old OFA effort to port the stack to Windows, IMHO, made a big<br>
>      mess. Ideologically requiring an old-at-the time MSVC compiler<br>
>      certainly contributed. Use a compiler that makes the port easy.<br>
><br>
>    Why not just say "use an operating system that makes the port easy"?<br>
>    It's completely ridiculous to argue that OS portability matters but<br>
>    compiler portability doesn't.  Be intellectually consistent and oppose<br>
>    the Windows port or stop discussing this issue altogether.<br>
<br>
That doesn't make any sense. A OS port is user a user visible top<br>
level feature. The toolchain is just a means to an end.<br>
<br>
I've got several software projects that are OS portable but not<br>
compiler portable (in the sense that they fully support many<br>
compilers, but often not the broken OS default one). I don't think<br>
that is inconsistent at all.<br>
<br>
Those projects require work to setup a build environment on certain<br>
OSs. That is less work than forever carrying patches for broken<br>
compiler support.<br>
<br></blockquote><div><br></div><div>This all assumes that compilers aren't OS/HW dependent beyond the ISA. This is not always true. Blue Gene/Q required a toolchain that aligned stacks to 32B instead of 16B, among other things. This is one reason why building GCC from source is nontrivial. </div><div><br></div><div>Jeff<span></span></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
It isn't for every project, but it is a very valid, and productive,<br>
way of approaching the problem.<br>
<br>
Especially now that the C standard bodies have worken up and are<br>
producing new standards more often. The C++ world feels this especially<br>
acutely.<br>
<br>
Jason<br>
</blockquote></div><br><br>-- <br>Jeff Hammond<br><a href="mailto:jeff.science@gmail.com" target="_blank">jeff.science@gmail.com</a><br><a href="http://jeffhammond.github.io/" target="_blank">http://jeffhammond.github.io/</a><br>