GCC 5.1 released
gcc.gnu.org
GCC 5.1 released
1–10 of 54 posts
Re: GCC 5.1 released
#2Some 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.
Re: GCC 5.1 released
#3Some 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…
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
Re: GCC 5.1 released
#4Jakub Jelinek's announcement on ML:
https://gcc.gnu.org/ml/gcc/2015-04/msg00287.html
And the same one for gmane lovers (like me):
Re: GCC 5.1 released
#5Some 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…
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
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.
Re: GCC 5.1 released
#6Some 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…
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
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.
Re: GCC 5.1 released
#7Some 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 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.)
Re: GCC 5.1 released
#8Some 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 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.
Re: GCC 5.1 released
#9I 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 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.
Re: GCC 5.1 released
#10I 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…
Sounds useful for wrappers, where you could conditionally compile to use either these builtins, or the annoying, potentially slow, portable versions.