LLVM's Clang C/C++ Compiler Is Still Having Problems With ~5% Of Debian Packages

[chuckatkins]

LLVM's Clang C/C++ Compiler Is Still Having Problems With ~5% Of Debian Packages

Unless these are compiler bugs like internal compiler errors, bad code generation, or failure to compile standard C++ code, the title here should really be inverted to read "~5% Of Debian Packages Are Still Having Problems With LLVM's Clang C/C++ Compiler"

[chuckatkins]

Also calling ICC "C/C++ compliant" would be pushing it.

I hate to burst your bubble but I've been maintaining build infrastructures for C++ code for >10y now across a sweeping array of compilers, and as far as closed source compilers go, ICC has consistently been the best there is w.r.t to compliance, at least within the past several years, with GCC and Clang typically not being any better, just different in the things they fail on.

ICC is known to take shortcuts by default, especially with floating point code (relaxed conformance or how they call it).

All compilers do this now but it's never a default, always an explicit option or group of options. O1 and O2, even on ICC, guarantee computational result parity with unoptimized code. You can turn on things like -Ofast which will trigger the less precise "fast" version of most intrinsics like sin, tan, sqrt, etc. These are options on GCC and clang as well virtually every other compiler, open or commercial.. They are not, however, on by default and any compiler that I've worked with for the past 10 - 15 y (Cray CCE, Sun/Oracle SunPro, Intel ICC, HP aCC, SGI MIPSPro, PGI, PathScale, MSVC even) just to name a few.

[Thaodan]

I would imagine KDE to do test with different compilers. Just look at http://clang.debian.net/status.php?v...CARD_ATTRIBUTE which was pointed out as a big source of build errors.

It's an issue with clang using a new C++14 feature thatr was a GCC feature.

[garegin]

ICC is proprietary and thus out of scope for Debian. They should waste no effort on supporting it.




The Debian project aims to create a libre operating system so it's natural that they require the compiler to be free software as well. Up until recently there were no other fully featured free C/C++ compilers other than GCC. I hope they'll eventually support Clang too.

My point was that why does the OS have to worry if some packages are written for GCC. Maybe GCC has a feature that I like that Clang doesn't. I think the dev should know BETTER what compiler he wants to use. This has been talked about before.

http://linuxhaters.blogspot.com/2008/07/feel-source.html?m=1

[chithanh]

http://linuxhaters.blogspot.com/2008...ource.html?m=1

Oh my goodness. Is this satire? Please tell me this is satire.

I feel dumber after reading this.

[chithanh]

I hate to burst your bubble

Thank you for your concern.

but I've been maintaining build infrastructures for C++ code for >10y now across a sweeping array of compilers, and as far as closed source compilers go, ICC has consistently been the best there is w.r.t to compliance,

All compilers do this now but it's never a default, always an explicit option or group of options. O1 and O2, even on ICC, guarantee computational result parity with unoptimized code.

Interesting, because in the past you needed to turn on "-fp-model strict" or "precise" in addition in order to avoid algebraic (e.g. associative) optimizations to your code, which are forbidden by language standards. When did this change?

Oh wait, it didn't change:

The default value of the option is -fp-model fast=1 or /fp:fast=1, which means that the compiler uses more aggressive optimizations on floating-point calculations.

https://software.intel.com/en-us/node/682946

They are not, however, on by default and any compiler that I've worked with for the past 10 - 15 y (Cray CCE, Sun/Oracle SunPro, Intel ICC, HP aCC, SGI MIPSPro, PGI, PathScale, MSVC even) just to name a few.

That is also interesting, because actual HPC folks are singing to a very different tune. Getting reproducible and consistent results out of floating point code across various compilers is a hard problem. And Intel's compilers are not exactly stalwarts of standards conformance in contrast to what you suggest above.

[DavidBrown]

Debian should build clean with ICC, GCC, Clang and any other C/C++ compliant compiler. The onus is on Debian to rip out any GCC customizations.

Why?

Debian is aiming to be free software, and the code needs to be built using free software. But why should a developer limit himself or herself solely to standards if a free tool gives them more than that? Why should a developer limit his or her build process to the common subset of options (basically just "cc") when using more compiler flags will give a better result?

clang is aiming for gcc compatibility on extensions and flags. This is a good thing - the cooperation/competition between clang and gcc has been good for both projects. But each also has different additional features. If a C++ programmer can write better code using "concepts", gcc is the only compiler to use. If "modules" are a useful feature, clang is the only (free) choice.

And Debian did not write the code being compiled here, nor did they write the compiler. They are quite happy using the common Linux build system to build their packages. This is just the clang team using the Debian source as a convenient source of code for testing their tools - which is great. But it is clang who are trying to make compatibility with gcc, and therefore it is clang that must make that effort.

[carewolf]

I hate to burst your bubble but I've been maintaining build infrastructures for C++ code for >10y now across a sweeping array of compilers, and as far as closed source compilers go, ICC has consistently been the best there is w.r.t to compliance, at least within the past several years, with GCC and Clang typically not being any better, just different in the things they fail on.

Sorry, these days ICC is behind even MSVC in standard compliance. They only just barely finished C++14 support. See http://en.cppreference.com/w/cpp/compiler_support

And that is on top of them enabling illegal standard violating optimizations by default.

[duby229]

My point was that why does the OS have to worry if some packages are written for GCC. Maybe GCC has a feature that I like that Clang doesn't. I think the dev should know BETTER what compiler he wants to use. This has been talked about before.

http://linuxhaters.blogspot.com/2008...ource.html?m=1

No offense to you at all, but that dude you linked is a complete moron. He obviously doesn't know a single damn thing about version control. He's obviously never contributed a single bug report ever. There is no doubt he's never bisected a single bug.

In my honest opinion, he's talking bullshit from his ass. He doesn't even know about the things he's talking about.