Curious if the folks at OpenBSD have ever thought about giving CompCert-C a shake. I realize it's no gcc or llvm, but OpenBSD is no run of the mill *nix, either.
The license of CompCert is an instant no to be part of base in openBSD.
I believe the reason openBSD hasn't changed to llvm is because it doesn't support all of their current architectures(feel free to correct me on this).
Not all compiler bugs are equal. Miod has a pretty good sense of which compilers exhibited the worst bugs in practice and the effort required to fix/workaround them.
Of course, everybody wants to have an LTS release of every piece of software they depend on, that "just works" for all their use cases [1], and that somebody else maintains for many years, like magic.
The problem is, nobody wants to pay for its maintenance, hence it does not exist [2].
Miod and I have different opinions. Anyway, what I think Miod really wants is a compiler free from regressions. Unfortunately, new compiler versions tend to introduce at least as many regressions as bug fixes.
That's not true for all open source projects. Look at PostgreSQL for instance, they back-patch all bugfixes (where possible) to all of the previous supported major versions.
Rust 1.0 represents a foundation for the language, rather than the ultimate expression of it. A LTS release could be a good idea, but I don't see it happening for at least a year or so.
The basic idea is that once released, the LTS version of the compiler would continue to receive fixes and updates for several years (at least two according to Wikipedia), no matter how many new versions are released during that time.
Also LTS means "95% of the developers left for the newer version because on open source projects no one can be forced to work on legacy applications like in business world".
Good luck with that. I tried to go on with the Ubuntu's LTS once, and the logic definitely doesn't work. Bugs, even major ones, just pile up faster than the remaining couple developers can fix, and it's was too painful of an experience to repeat. Ubuntu LTS has shelf life of 6-12 months unless if you start paying. Which is unfortunate.
95% of the developers left for the newer version because on open source projects no one can be forced to work on legacy applications
Yep. I see this a lot in the scientific world. Clusters and other high-performance hardware run old versions of Scientific Linux or CentOS (because they are well-supported and the bugs are known). However, a lot of open source project (e.g. in machine learning) expect you to run the latest Ubuntu or OS X version. Result: you usually end up hand-compiling large amounts of software, manually adding '-I' and '-L' flags to oddball build systems that don't pick up CFLAGS or LDFLAGS correctly.
Nobody cares about backwards compatibility, everyone wants the new toys.
I want "something", that something being backwards compatibility and long-term support, for $100-150. Can I get it from Ubuntu or any other Linux/Unix? I sure as hell get it from Microsoft.
Great place to shamelessly mention my MIT licensed work in progress C compiler (written in Go), https://github.com/andrewchambers/cc/ . Nowhere near the level it needs to be, but would be fun if I could start a community to push it forward.
Depends on your code. C isn't moving at the pace C++ is so given that most (all?) of the OpenBSD base is C and sh, LTS will work with base, no problem. It's important too that developers are rather happy with what C99 brings to the table so it's a solid reference point for any LTS compiler that would/could happen. It's ports, I think, where the problem is. A lot of that code is C++ so you need compiler and std lib implementation to be able to handle it. But there are two problem.
First one: the quality of ports varies from project to project. There's code out there that depends on certain gcc-specific extension, compiler quirks, bugs, you name it. C++ is insanely complex and features just keep piling on. I bet the moment C++17 is available some projects start using certain features because they can. In this case C++ is a moving target and it's hard to imagine LTE C++ compiler for open source projects.
Second one: AFAIK only gcc's standard library has support for all of the wacky constructs C++ requires. You're probably out of luck if you try to compile C++ code with thread local storage intermingled with exceptions and you want to depends on non-GPL musl or bionic (which would be important for projects like OpenBSD). And there's code depending on that in ports, you can bet on it.
Until these problems are solved[1], OpenBSD won't migrate. LLVM could become the LTS compiler for projects that would benefit from using it, but it doesn't look like a complete operating system is a project that would fit.
[1] plus some others, like backends available for more than x86/64, arm, mips, PPC, Sparc and z (or whatever the list is today); OpenBSD supports quite a few esoteric platforms
Traditionally on most Unix systems cc and gcc where two different compilers. Many times people would write code in ways that compiled with gcc, but not cc, so specifying exactly which compiler you want makes sense.
It might be bit ugly, but couldn't you use a variable inplace of the compiler name, so that it would be trivial for someone to attempt using another compiler
This is only relevant if you want portability to other versions of Make. I simply don't care about anybody who's not using GNU Make these days. Try it yourself: command line options override variables in makefiles unless "override" is specified for that assignment.
http://compcert.inria.fr/compcert-C.html
EDIT: See also https://github.com/AbsInt/CompCert