Some of these are terrific changes! E.g., OpenMP 4.0 and Cilk Plus support, wew! I also love that ``gcc`` now defaults to ``-std=gnu11`` instead of ``-std=gnu89``; what a huge step forward! But, there were a couple of things in here that I was hoping to see but did not find (namely, it seems gcc still does not have ``-Weverything``).
While I am glad to see gcc making progress, I feel bound to clang until gcc's warning/error reporting can get up-to-speed.
GCC 5.1 defaults to having color diagnostics set to `auto`, meaning it will display nice, beautiful diagnostics like Clang does on your terminal, if that's what you're referring to. (You can also get these with GCC 4.9, too, using the `GCC_COLORS` environment variable).
Personally I don't care about that as much as the optimization improvements this time arond, it seems. Better devirtualization? AutoFDO? Reuse of the PIC hard register, especially? (That will be a great win on 32 bit machines, and makes it all the more possible to enable things like PIE for 32-bit applications, where it would otherwise be a big penalty, as well as many other things.)
Haha, I wasn't actually referring to colored warning/error output (though it is a nice plus!). I was mostly referring to `clang`'s `-Weverything` and the absence of any such alias for `gcc`.
> namely, it seems gcc still does not have ``-Weverything``
I would love to have a -Weverything; as a fairly rusty C++ dev I originally thought -Wall was supposed to have, you know, all but was pretty surprised to learn it didn't actually contain all. It would be great if they deprecated -Wall and made it so -Weverything always did all warnings (including any newly introduced warnings).
Clang's -Weverything isn't really as useful as it sounds; since it includes fairly-to-completely useless warnings like -Wc++98-compat, -Wpadded, or -Wweak-vtables, you'll end up spending so much time playing warning whack-a-mole that you might as well have not enabled the thing in the first place. At least that's been my experience.
I completely disagree. It's true that some of the warnings it enables aren't terribly useful, but being able to enable all warnings is very helpful instead of having to manually list ~40 flags. Additionally, -Wpadded and the like are actually helpful for optimizations.
Plus, writing code (in C, I cannot speak for Cxx) which results in no warning output from `-Weverything` is actually not that difficult to do, and generally the result is that you've written more robust code in the process. A lot of projects are now trying to move to compile with `-Weverything` and not disable any warnings, and I personally think it's a great move.
For C, I'd agree that it's useful. The flags I listed have issues specifically for C++. -Wc++98-compat, on a C++11 or C++14 project, is about as helpful as you'd expect. -Wpadded is triggered pretty reliably by subclassess. And so forth.
Of course it is possible to specifically disable useless warnings, but in my experience it's just as easy to add a reasonable selection of flags (say, -Wall -Wextra -Wold-style-cast -Wconversion -Wsign-conversion) than to start with -Weverything and work backwards. Still, it has been some time since I've tried using it; maybe I ought to give it another chance.
Here's a detailed explanation of -Weverything from a clang developer. He says -Weverything is intended for clang developers' own testing. He recommends using -Wall -Wextra plus any individual warnings you may want.
I do not personally code in Cxx (which is why I refrained from making judgements about `-Weverything`'s use for it earlier). But, at least for C, almost all the warnings you get are helpful (with very few exceptions). At most, I end up disabling two or three warnings from `-Weverything` on my projects. And, personally, I prefer to use pragmas inside the code rather than flags to disable them; that way, I can explicitly declare in my code that I have intentionally done something which would raise a warning (as close to the actual something as possible rather than generally disabling it).
The result is that I still get the warnings for wherever I did not intentionally invoke these actions and still get all the other warnings that I should pay attention to for best practices.
Though I would personally argue for most people (particularly new C coders) using `-Weverything` wherever possible, if you see fit not to, that's your choice :)
The -Wmaybe-uninitialized flag can produce loads of false positives, and may not be very useful (depending on your code). The really interesting part is that a compiler that gives 100% correct warnings about using uninitialized variables can be proven to be able to solve the halting problem, thus it cannot exist.
Then again, if you construct your code such that determining whether a variable is initialized requires solving the halting problem, somebody should probably take your keyboard away :-).
In practice, if your initialization isn't sufficiently transparent, you're just busy making bugs.
The only problem I have with keeping `-Wall` is that it's misleading. But, other than that, I don't mind keeping it around so long as there is an option that enables all warnings. And since 5.1 includes a few more fancy new warnings, it'd be great to see those added into this hypothetical `-Weverything` as well. But, the issue on their bugtracker for inclusion of this feature was opened during 4.8 and still hasn't been confirmed for a release to target… makes me SadInside™.
Misleading options and unnecessary inconsistencies should be frowned upon. They make it harder to learn a system and learning a system should be made as easy as possible. I'd consider consistency in regards to option availability, effect and syntax a top priority.
Learning a system is important, but it doesn't always warrant breaking existing systems. If GCC were to reject the -Wall argument, many projects which have used it for years would break and now need an extra GCC version-check embedded into their build tools.
The gcc manpage would be an appropriate place for developers to document any preferred replacement for -Wall, for new projects. Anyone learning build tools is likely to hit the manpages, and anyone who learns-by-google is still likely to see it in HTML ports of the manpages.
The libre and open software community is way too considerate with existing users. Combine that with anarchistic development and you get the inconsistent and complex mess we ended up with.
Debian is _horrible_. And it will never be good without radical changes, possibly including changing options and syntax of commands, breaking API's and ABI's and breaking every running instance of it.
Just look at basic commands. It's 'cp ifile ofile' but 'dd if=ifile of=ofile'. This one-of-many wart has to go, exiled together with all its siblings.
Common shell languages like sh and it's children are nightmarish abominations, unintuitive and unsafe - they deserve to die in flames.
We need change. A change for the better; for intuitiveness, for elegance, conformity, consistency, for learnability. Until then, Windows and Apples OS will stand a chance.
Intelligent design is what we need, not only evolution.
Yeah, as has been mentioned many times before `-Wall -Wextra` leaves out a ton of warnings/errors (despite what the names imply). `-Weverything` is an alias for enabling all warnings. I find it much better practice to enable all warnings and then selectively disable the ones which warn me about things I have done intentionally through pragmas in the code.
While I am glad to see gcc making progress, I feel bound to clang until gcc's warning/error reporting can get up-to-speed.