GCC 5.1 released

https://gcc.gnu.org/gcc-5/changes.html

by fs111 • 11 years ago

208 50 11 years ago

gcc.gnu.org

halosghost6• 11 years ago

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.

reidrac• 11 years ago

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

mkaufmann• 11 years ago

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.

halosghost6• 11 years ago

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.

thoughtpolice• 11 years ago

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

halosghost6• 11 years ago

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

BinaryIdiot• 11 years ago

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

jeorgun2• 11 years ago

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.

halosghost6• 11 years ago

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

nn3• 11 years ago

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

Not particularly useful though.

przemoc• 11 years ago

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

ploxiln• 11 years ago

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

mikeash• 11 years ago

Sounds useful for wrappers, where you could conditionally compile to use either these builtins, or the annoying, potentially slow, portable versions.

cremno• 11 years ago

Sadly clang (the origin of those built-in functions) doesn't implement the type-generic ones and GCC doesn't implement __has_builtin yet.

Someone• 11 years ago

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

madez3• 11 years ago

This is a good example of how competition is contribution.

yuhong• 11 years ago

There is also _addcarry_u32 and _subcarry_u32

rurban• 11 years ago

I use them for some time now with

    +#if (defined(__clang__) && ((__clang_major__ > 3) \
    +                         || (__clang_major__ == 3 &&     __clang_minor__ >= 4))) \
    + || (defined(__GNUC__) && __GNUC__ >= 5)

ehmmm• 11 years ago

It is so close to full C11 support.

I think just threads.h are missing now.

bstamour• 11 years ago

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?

huu2• 11 years ago

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.

jbrandmeyer• 11 years ago

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.

justincormack• 11 years ago

Musl libc has a c11 threads implementation.

wnissen• 11 years ago

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_why_of_y• 11 years ago

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.

jcoffland• 11 years ago

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.

stefantalpalaru• 11 years ago

Any news about escape analysis for gccgo?

JoeAltmaier2• 11 years ago

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

JoachimSchipper2• 11 years ago

volatile works, asm works, and it's usually not hard to trick the optimizer.

TheLoneWolfling3• 11 years ago

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.

JoeAltmaier2• 11 years ago

I wondered about 'volatile'. Its not really meant for that - but maybe its enough to trigger 'hands off'.

mattgodbolt• 11 years ago

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.

GCC 5.1 released

Related Stories