Live data from Hacker News

GCC 5.1 released

gcc.gnu.org

21–30 of 54 posts

Re: GCC 5.1 released

#21
post #20

Earlier quoted context omitted.

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 gen…

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…

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 :)

Re: GCC 5.1 released

#22
Whoa, this is the first time the ABI has been deliberately broken since, what, 3.4? I see it's due to the small string optimization and a std::list that tracks its size, which will be nice but I don't know it's worth breaking compatibility for that by default. Still, it's an impressive string of compatibility, and I applaud the maintainers. I've successfully built 4.9.0 against 4.1.2 with exceptions, etc. and it Just Works.

Re: GCC 5.1 released

#23
post #9

I won't be able to use them in portable code anytime soon, but the new feature here that most interests me is __builtin_add_overflow, __builtin_sub_overflow and __builtin_mul_overflow "These builtins have two integral arguments (which don't need to have the same type), the arguments are extended to infinite precision signed type, +, - or * is performed on those, and the result is stored in an integer variable pointed…

There is also _addcarry_u32 and _subcarry_u32

Re: GCC 5.1 released

#24
post #14
post #9

I won't be able to use them in portable code anytime soon, but the new feature here that most interests me is __builtin_add_overflow, __builtin_sub_overflow and __builtin_mul_overflow "These builtins have two integral arguments (which don't need to have the same type), the arguments are extended to infinite precision signed type, +, - or * is performed on those, and the result is stored in an integer variable pointed…

That may be sooner than you think, depending on what you mean by portable. I think these functions originated as non-generic versions in clang ( http://clang.llvm.org/docs/LanguageExtensions.html#builtin-f... ). gcc copied them and now added generic variants. I think it is likely that clang will now copy gcc and add the generic variants. Edit: here is the request for gcc to copy clang: https://gcc.gnu.org/bugzilla/sh…

This is a good example of how competition is contribution.

Re: GCC 5.1 released

#25

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 warnin…

gcc $(gcc -v --help 2>&1 | awk '/-W/ && !/=/ && !/[oO]ptions/ && !/larger-than/ { print $1 }')

Not particularly useful though.

Re: GCC 5.1 released

#26
post #20

Earlier quoted context omitted.

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 gen…

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…

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.

http://programmers.stackexchange.com/a/124574

clang does not document its warning flags like gcc does, but a long (but now incomplete) list is available here:

http://fuckingclangwarnings.com/

Re: GCC 5.1 released

#27
post #22

Whoa, this is the first time the ABI has been deliberately broken since, what, 3.4? I see it's due to the small string optimization and a std::list that tracks its size, which will be nice but I don't know it's worth breaking compatibility for that by default. Still, it's an impressive string of compatibility, and I applaud the maintainers. I've successfully built 4.9.0 against 4.1.2 with exceptions, etc. and it Just…

The changes were necessary so that libstdc++ conforms to the C++11 standard, which introduced new requirements on std::list and std::string.

And this time they managed to do it without a SONAME bump, which is nice.

Re: GCC 5.1 released

#28

Earlier quoted context omitted.

> 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).

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 be…

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.

Re: GCC 5.1 released

#29
post #19

It is so close to full C11 support. I think just threads.h are missing now.

I haven't really heard much buzz about C11 since its release. I don't mean to sound snarky (I'm really curious): does anyone really use C11 at all?

Re: GCC 5.1 released

#30
It seems like the GCC guys have really kicked it up a notch. I think LLVM has inspired them to move it or loose it. At this rate they can expect to still be a relevent compiler system for a very long time.
Post reply on HN