gcc 9.1.1 released

[Shelwien]

https://www.phoronix.com/scan.php?pa...piler-Released

https://gcc-mcf.lhmouse.com/

Other places to look for windows toolchains (no gcc9 yet):

http://mingw-w64.org/doku.php/download
https://sourceforge.net/projects/mingw-w64/files/
https://osdn.net/projects/sfnet_mingw-w64/
http://www.msys2.org/

https://nuwen.net/mingw.html

Did a small benchmark with my recent CM coder, somehow gcc82 wins?

    x32
book1  wcc386
3.422s 2.984s:  CMo8-gcc82-x32-SSE4
3.610s 3.234s:  CMo8-gcc91-x32-SSE4
4.266s 3.640s:  CMo8-ic19-x32-ia32-PGO
4.235s 3.656s:  CMo8-ic19-x32-SSE4-PGO
3.594s 3.219s:  CMo8-ic19-x32-SSE4

    x64
book1  wcc386
3.265s 2.860s:  CMo8-gcc82-x64-native
3.281s 2.859s:  CMo8-gcc82-x64-SSE4
3.468s 3.000s:  CMo8-gcc83-x64-SSE4
3.313s 2.937s:  CMo8-gcc91-x64-native
3.484s 3.047s:  CMo8-gcc91-x64-SSE4
3.422s 3.094s:  CMo8-gcc91-x64-SSE4-PGO
3.188s 2.781s:  CMo8-ic19-x64-SSE4-PGO
3.437s 3.062s:  CMo8-ic19-x64-SSE4

[Bulat Ziganshin]

People say that GCC 9.1 is already in MYSY2 (I've not tried it myself!):

pacman -S[w] mingw-w64-x86_64-gcc mingw-w64-x86_64-gdb mingw-w64-x86_64-make mingw-w64-x86_64-tools-git mingw-w64-x86_64-gcc-fortran mingw-w64-x86_64-gcc-libs

[xcrh]

Did a small benchmark with my recent CM coder, somehow gcc82 wins?

If you take a look on phoronix in more details and then dig compiler devs mailing lists and somesuch, you'll eventually notice code optimization is a very tricky business. So when new compiler released it isn't unusual to get code larger or smaller on particular algo. Same for speed. To make it more complicated, unless you specify -march/-mcpu/-mtune, compiler targets something "generic", it is debatable what kind of compromises is to be taken to perform reasonably everywhere. There is nothing wrong in eventually changing notion of "reasonable".

Long story short, when it comes to compilers, on new release some platforms/(sub-)archs win, some lose. Some algos win, some lose. It is rare to see TOTAL regression, where compiler would perform worse on all algos and cpu flavors - it usually prevents release until regression fixed. Yet it also eventually possible. If code generation regression hurts and seems to affect more than 1 algo, and especially on different -march/-mtune/-mcpu it can make sense to file a bug.

Most funny part? If you obsessed by just one particular CPU core flavor and algo, measuring only these, it not to be taken as granted latest compiler would always be best choice. However it doesn't really tells much about overall code generation quality of compiler. It takes a lot of measurements on various algos to get anyhow reasonable idea on this. Some phoronix benchmarks can give coarse idea how it could appear. I bet it same with clang, with exception early versions had crappy optimizer but fast compile time, and now it got comparable optimizer ... and comparable compile times, because it's not like if one can have free lunch

Side note: I've had some fun measuring ARM Cortex code generation vs various GCCs, interestingly, I've been mostly interested in smallest code size and RAM use, while performance is "good to have" but not really pressing matter. Across GCC 6.x to 8.3 it proven to be rather "chaotic" but fun to measure. In this particular cpus bloodline, code generation basically evolved making code slightly larger but considerably faster (somehow affecting even -Os). Ironically it wasn't what I really wanted under my assumptions, but tradeoff looked very sane. After all I dodged the bullet by changing CPU type to target crappy cortex-M0 cores. Cortex M0 got far more crippled instruction set (compared to M3 I really had), so generated code is considerably slower (underusing core capabilities). Yet, somehow, it also makes code size noticeably smaller, while target CPU still can run that code (at which point mission accomplished). So for me smallest combo been GCC 7 in M0 mode. Previous and later compilers lose to this combo (by rather low margins, but it really depends on how much you're pressed by system resources).

p.s. if someome is obsessed on code size (e.g. for small systems), GCC got fairly neat thing, called LTO. It brings no speed penalty - but can reduce code size, eliminating unreachable/unused code. Ironically it does its job so damn well that in standalone environment it eliminated me WHOLE FIRMWARE (!!!), failing to see its entry point is used. I failed to persuade LTO in this setup my code is "used", though GCC also supports yet another cheat, putting all functions and vars to own sections - and then pruning unused ones. This trick worked, chopping code size considerably. However LTO is more radical and efficient at this. In small systems there is inherent catch - say, interrupt handlers are inherently "unused" - rest of code never calls them.

p.p.s. if one needs for speed, gcc also got ton of "less reliable" things to try. -O5...9 could work. Or not. Same for -ffast-math, -funsafe-loop-optimizations and so on. One can get better performance at cost of incomplete compliance with standards, so some code would break. But most algos can get with it - eventually getting faster. If it's all that matters, it could be way to go.