GCC 5.2 released • Hacker News Board

Re: GCC 5.2 released

#31

Post by uxcn » Thu, Jul 16, 2015, 7:02 PM UTC

rst wrote: post #25

agwa wrote: post #14

It's worth noting that, due to GCC's new and esoteric version numbering scheme[1], this is a bugfix-only release on the 5.x branch. The bigger news was when GCC 5.1 (a major stable release) was released in April. That said, GCC 5.2 fixes a pretty serious bug that I was hitting so I'm happy to hear about it! [1] https://gcc.gnu.org/develop.html#num_scheme

They switched the default C compilation mode from --std=gnu89 to --std=gnu11 in a bugfix-only release?

I hope more projects start using it (or C99) over C89.

Re: GCC 5.2 released

#32

Post by pcwalton » Thu, Jul 16, 2015, 7:34 PM UTC

spacehome wrote: post #19

the8472 wrote: post #7

> Write-only variables are now detected and optimized out. That's probably something one should keep in mind when writing micro-benchmarks.

I'm appalled that this wasn't taken care of 20 years ago. It seems like such low-hanging fruit.

I assume it means globals, which is significantly less trivial. Any SSA-based compiler, which GCC has been for years and years, trivially does this for locals.

Re: GCC 5.2 released

#33

Post by anon4 » Thu, Jul 16, 2015, 7:55 PM UTC

greglindahl wrote: post #23

spacehome wrote: post #19

Earlier quoted context omitted.

I'm appalled that this wasn't taken care of 20 years ago. It seems like such low-hanging fruit.

This is a standard compiler feature, yes -- lots of real code out there has a lot of dead writes, such as debugging code that has been only partly removed or disabled. Historically, it's been a significant win for some of the SPECcpu benchmarks.

Historically, it's been a significant win for some of the SPECcpu benchmarks.

But doesn't it mean that you're not really executing the full benchmark then?

Re: GCC 5.2 released

#34

Post by minot » Thu, Jul 16, 2015, 8:20 PM UTC

Hi guys, any idea when we might get this on mingw?

Re: GCC 5.2 released

#35

Post by greglindahl » Thu, Jul 16, 2015, 8:40 PM UTC

anon4 wrote: post #33

greglindahl wrote: post #23

Earlier quoted context omitted.

This is a standard compiler feature, yes -- lots of real code out there has a lot of dead writes, such as debugging code that has been only partly removed or disabled. Historically, it's been a significant win for some of the SPECcpu benchmarks.

Historically, it's been a significant win for some of the SPECcpu benchmarks. But doesn't it mean that you're not really executing the full benchmark then?

No, because no one ever reads the dead data. These are not microbenchmarks that get broken by optimizations like this; SPECcpu programs have answers, and the goal is to output the answer. The answer is tested. Anything you can delete from the program is fair game.

Re: GCC 5.2 released

#36

Post by anon3_ » Thu, Jul 16, 2015, 10:38 PM UTC

Where is GCC's place in the world now that there is LLVM/Clang?

Does the LLVM+Clang combo make GCC obsolete?

Re: GCC 5.2 released

#37

Post by rossy » Thu, Jul 16, 2015, 11:34 PM UTC

minot wrote: post #34

Hi guys, any idea when we might get this on mingw?

If you're using MSYS2 to get your MinGW compilers, the package has been updated, but you won't see builds on the mirrors until all the other packages have been rebuilt for GCC 5.1/5.2 (due to the ABI change.)

https://github.com/Alexpux/MINGW-packages/commit/a6a16a3

Re: GCC 5.2 released

#38

Post by astrange » Fri, Jul 17, 2015, 12:53 AM UTC

greglindahl wrote: post #23

spacehome wrote: post #19

Earlier quoted context omitted.

I'm appalled that this wasn't taken care of 20 years ago. It seems like such low-hanging fruit.

This is a standard compiler feature, yes -- lots of real code out there has a lot of dead writes, such as debugging code that has been only partly removed or disabled. Historically, it's been a significant win for some of the SPECcpu benchmarks.

It's standard to remove local variables that are write-only, but globals aren't always defined to be unused even when you want them to be. If you're building a shared library and you exported the symbol, it has to leave it in as part of the API.

Link-time optimization can delete a lot more stuff when you're building a program directly, since it only has to keep main()… as long as you didn't go and use things like function pointers.

This is one reason I try to use '-fvisibility=hidden' in libraries, because it prevents anything from being part of the API unless you go back and specifically export it.