GCC 12 Still Has More Regressions To Stomp Before Release

[phoronix]

Phoronix: GCC 12 Still Has More Regressions To Stomp Before Release

GNU Compiler Collection developers are working towards the stable release of GCC 12 in the next month or so as GCC 12.1. A GCC status report was issued today and there still is just under two dozen regressions of the highest priority (P1) to address or otherwise demote those regressions to lower priority...

https://www.phoronix.com/scan.php?page=news_item&px=GCC-12-More-P1-Regressions

[NateHubbard]

But I just switched to GCC 11.

[uid313]

How does GCC compare against LLVM/clang, and compilers from AMD, Intel and Microsoft?

[oleid]

How does GCC compare against LLVM/clang, and compilers from AMD, Intel and Microsoft?

In what respect?

Last time I checked AMD's compiler was a fork of clang. Microsoft and Intel are using clang's frontend, but have their own code generator backends. So in essence, clang is to gcc what 'blink' is to gecko. With one difference: gcc's generated code is usually not slower than clang's code.

[oiaohm]

How does GCC compare against LLVM/clang, and compilers from AMD, Intel and Microsoft?

Last time I checked AMD's compiler was a fork of clang. Microsoft and Intel are using clang's frontend, but have their own code generator backends. So in essence, clang is to gcc what 'blink' is to gecko. With one difference: gcc's generated code is usually not slower than clang's code.

https://www.phoronix.com/scan.php?page=article&item=aocc32-clang-gcc

There are different benchmarks at different times comparing compilers. The reality is Gcc and LLVM based compilers are generally inside 5% of each other in performance in generated code with gcc sometimes winning. To be correct the differences in performance more often than not are inside margin of error. This is not surprising thinking AMD and Intel both do work on gcc mainline as well as their own forked LLVM based stuff so the core technologies here are kind of shared.

Microsoft compiler MSVC is a totally different here. https://pvs-studio.com/en/blog/posts/cpp/0830/ Parties like this one are finding huge performance uplifts switching to either LLVM or gcc. This one is over 10% uplift going to LLVM but the highest you see 150% as in taking 1/4 of the time to run switching to either LLVM or GCC. Of course the switch is not without it pain. Lot of this problem is Microsoft MSVC not keeping up with new CPU instruction sets or new things found about existing instructions sets with field deployed silicon.

The reason why MSVC is not keeping up with new Instruction sets or new things found about existing instructions sets with field deployed silicon is simple AMD and Intel and many other hardware platform developers don't code core MSVC core code. These internal developers of hardware companies have access to hardware platforms well before Microsoft can also have access to hidden stuff like reported security flaws. So the only way MSVC can catch up here is for Microsoft basically to come a chip designer or open up their code base.

I do have to wonder with different bits of LLVM support being added to Visual studio Microsoft at some point will just give up on MSVC.

Please note some projects like Libreoffice use a mix of MSVC and LLVM to build on Windows. LLVM being used for performance critical areas. Lot of ways MSVC usage is dropping and the driving force is performance. The libreoffice usage of LLVM is not using the Microsoft back-end neither is the pvs-studio one.

Do note projects that support complete building with llvm and gcc will build the complete project in one or the other because there is no real advantage other than extra headaches that using 2 compilers cause. Basically a lot has to be wrong for people wanting to build a project using 2 compilers with 2 different back-ends.

This is the hard reality if a compiler is not LLVM based or Gcc these days you are fairly much sure of getting poor performance. There is only rare exceptions for this and that is compilers targeting embedded platforms that LLVM and Gcc basically don't support so that is really higher performance because we don't work not as in being technically better. Its not just Microsoft that has fallen into bad performance camp. Do note I said these days this has really happened over the last 5-7 years.
Like back in 2015 you would find a lot of different compilers that could beat either Gcc or LLVM or both that were closed source. Yes the performance difference between LLVM and Gcc was wider in benchmarks 5-7 years ago.

The performance difference between gcc and llvm is basically narrowed over the last 5-7 yearsl as the performance of gcc and llvm increasing this is slowly leaving everything else in the dust.

[uid313]

https://www.phoronix.com/scan.php?page=article&item=aocc32-clang-gcc

There are different benchmarks at different times comparing compilers. The reality is Gcc and LLVM based compilers are generally inside 5% of each other in performance in generated code with gcc sometimes winning. To be correct the differences in performance more often than not are inside margin of error. This is not surprising thinking AMD and Intel both do work on gcc mainline as well as their own forked LLVM based stuff so the core technologies here are kind of shared.

Microsoft compiler MSVC is a totally different here. https://pvs-studio.com/en/blog/posts/cpp/0830/ Parties like this one are finding huge performance uplifts switching to either LLVM or gcc. This one is over 10% uplift going to LLVM but the highest you see 150% as in taking 1/4 of the time to run switching to either LLVM or GCC. Of course the switch is not without it pain. Lot of this problem is Microsoft MSVC not keeping up with new CPU instruction sets or new things found about existing instructions sets with field deployed silicon.

The reason why MSVC is not keeping up with new Instruction sets or new things found about existing instructions sets with field deployed silicon is simple AMD and Intel and many other hardware platform developers don't code core MSVC core code. These internal developers of hardware companies have access to hardware platforms well before Microsoft can also have access to hidden stuff like reported security flaws. So the only way MSVC can catch up here is for Microsoft basically to come a chip designer or open up their code base.

I do have to wonder with different bits of LLVM support being added to Visual studio Microsoft at some point will just give up on MSVC.

Please note some projects like Libreoffice use a mix of MSVC and LLVM to build on Windows. LLVM being used for performance critical areas. Lot of ways MSVC usage is dropping and the driving force is performance. The libreoffice usage of LLVM is not using the Microsoft back-end neither is the pvs-studio one.

Do note projects that support complete building with llvm and gcc will build the complete project in one or the other because there is no real advantage other than extra headaches that using 2 compilers cause. Basically a lot has to be wrong for people wanting to build a project using 2 compilers with 2 different back-ends.

This is the hard reality if a compiler is not LLVM based or Gcc these days you are fairly much sure of getting poor performance. There is only rare exceptions for this and that is compilers targeting embedded platforms that LLVM and Gcc basically don't support so that is really higher performance because we don't work not as in being technically better. Its not just Microsoft that has fallen into bad performance camp. Do note I said these days this has really happened over the last 5-7 years.
Like back in 2015 you would find a lot of different compilers that could beat either Gcc or LLVM or both that were closed source. Yes the performance difference between LLVM and Gcc was wider in benchmarks 5-7 years ago.

The performance difference between gcc and llvm is basically narrowed over the last 5-7 yearsl as the performance of gcc and llvm increasing this is slowly leaving everything else in the dust.

Thank you for a great post! 👍

[xorbe]

Why do the mailing list posts keep referring to releasing GCC 13?