GCC 5.1 released(gcc.gnu.org)
gcc.gnu.org
GCC 5.1 released
https://gcc.gnu.org/gcc-5/changes.html
10 comments
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/show_bug.cgi?id=59708 (nice discussion about the need to have builtins for overflow detection)
And here is a request for clang to copy gcc's generic versions: https://llvm.org/bugs/show_bug.cgi?id=21716
Edit: here is the request for gcc to copy clang: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59708 (nice discussion about the need to have builtins for overflow detection)
And here is a request for clang to copy gcc's generic versions: https://llvm.org/bugs/show_bug.cgi?id=21716
This is a good example of how competition is contribution.
Sounds useful for wrappers, where you could conditionally compile to use either these builtins, or the annoying, potentially slow, portable versions.
Sadly clang (the origin of those built-in functions) doesn't implement the type-generic ones and GCC doesn't implement __has_builtin yet.
I use them for some time now with
+#if (defined(__clang__) && ((__clang_major__ > 3) \
+ || (__clang_major__ == 3 && __clang_minor__ >= 4))) \
+ || (defined(__GNUC__) && __GNUC__ >= 5)There is also _addcarry_u32 and _subcarry_u32
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.
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.)
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).
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.
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.
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.
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/
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/
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 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.
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 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.
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.
[deleted]
Apparently -Wall and -Wextra is believed to be enough; not sure what to expect with -Weverything but I'm intrigued :)
EDIT: interesting indeed. Thanks for the pointer!
(Add warning levels) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53313
EDIT: interesting indeed. Thanks for the pointer!
(Add warning levels) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53313
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.
I like to use -Wpedantic for my own projects to keep the code clean and it helped my well. Its not included in -Wall and -Wextra.
gcc $(gcc -v --help 2>&1 | awk '/-W/ && !/=/ && !/[oO]ptions/ && !/larger-than/ { print $1 }')
Not particularly useful though.
Not particularly useful though.
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.
Jakub Jelinek's announcement on ML:
https://gcc.gnu.org/ml/gcc/2015-04/msg00287.html
And the same one for gmane lovers (like me):
http://thread.gmane.org/gmane.comp.gcc.devel/139625
https://gcc.gnu.org/ml/gcc/2015-04/msg00287.html
And the same one for gmane lovers (like me):
http://thread.gmane.org/gmane.comp.gcc.devel/139625
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.
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.
And this time they managed to do it without a SONAME bump, which is nice.
It is so close to full C11 support.
I think just threads.h are missing now.
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?
I use C++11 and it's awesome. It's expressive like python but still maintains strict type safety. I built a (still young) curl wrapper using C++11: https://github.com/whoshuu/cpr
Edit: Misread the parent posts and thought they were referring to C++11. Today I learned C11 is a separate standard.
Edit: Misread the parent posts and thought they were referring to C++11. Today I learned C11 is a separate standard.
Isn't that C++11?
Nice looking project but unfortunately it is GPL.
Unlike Curl it self because it uses MIT like license.
Too bad proprietary projects can't link against it. A loss for us all.
Seriously? GPL stuff can be used with any internal stuff, and almost any Free stuff. Isn't that enough? Where is the loss exactly?
Edit: okay, that wasn't the author's intention, and the consistency argument is a good one (least astonishment and all that). Still, the general argument holds.
Seriously? GPL stuff can be used with any internal stuff, and almost any Free stuff. Isn't that enough? Where is the loss exactly?
Edit: okay, that wasn't the author's intention, and the consistency argument is a good one (least astonishment and all that). Still, the general argument holds.
Excellent point, I just changed the license to MIT to be consistent with curl. Thanks for catching that.
that looks like a c++ project that uses c++11 not c11
As an embedded programmer, I have to say that C11 atomics are a much better fit for device register access than volatile. Unfortunately, since many commercial C compilers don't even support C99 fully, I don't expect to see C11 in common use anytime soon.
Musl libc has a c11 threads implementation.
Took a little longer than I'd hoped but GCC explorer now has support for GCC 5.1 : https://gcc.godbolt.org
It doesn't support LTO as yet due to the way it works so some of the juicier optimisations aren't visible. But you still get a chance to play about with the quality of the code generator.
It doesn't support LTO as yet due to the way it works so some of the juicier optimisations aren't visible. But you still get a chance to play about with the quality of the code generator.
I'm troubled that 'write-only variables are ... optimized out'. That means, no more embedded trace buffers in memory dumps? I've used that for decades to debug intermittent problems. Maybe there's some way to tag necessary write-only variables...
volatile works, asm works, and it's usually not hard to trick the optimizer.
It's becoming harder to trick the optimizer all the time.
I mean, the goal of an optimizer is literally not to be able to be tricked into doing work it doesn't have to.
I mean, the goal of an optimizer is literally not to be able to be tricked into doing work it doesn't have to.
Yes; e.g. http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libc/string... demonstrates that rather well. Still, it is and will remain possible - and for the intended use, that's probably good enough. (It's not write - and - forget code where tricking the optimizer is security-critical.)
If you're having to trick the optimizer, you're doing something wrong.
If the language is such that there are things in the language that inherently require tricking the optimizer, the language is doing it wrong.
If the language is such that there are things in the language that inherently require tricking the optimizer, the language is doing it wrong.
I wondered about 'volatile'. Its not really meant for that - but maybe its enough to trigger 'hands off'.
Practically speaking, 'volatile' has used for that pretty much since its inception.
Yep, even though it really shouldn't be.
Volatile has... problems. It was meant more for mem-mapped IO than thread safety.
And it's too powerful at the same time, as in there are a number of optimizations that are safe in the typical use cases of volatile that cannot be done to volatile variables.
Volatile has... problems. It was meant more for mem-mapped IO than thread safety.
And it's too powerful at the same time, as in there are a number of optimizations that are safe in the typical use cases of volatile that cannot be done to volatile variables.
Any news about escape analysis for gccgo?
"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 to by the last argument. If the stored value is equal to the infinite precision result, the built-in functions return false, otherwise true. The type of the integer variable that will hold the result can be different from the types of the first two arguments."
Handling all possible integer overflow with plain C is annoyingly tricky and for some critical paths in-efficient. These built-ins can often do a conditional jump based on the overflow bit in the flags register.