[Development] [RFCs] Migrate from GCC MinGW to LLVM MinGW

[Thiago Macieira]

On Wednesday, 19 July 2023 08:46:27 PDT Cristian Adam via Development wrote:
> Hi,
> 
> we are thinking of migrating from GCC MinGW to LLVM MinGW. The ticket in
> question is [QTBUG-107516] Migrate from GCC MinGW to LLVM-MinGW - Qt Bug
> Tracker<https://bugreports.qt.io/browse/QTBUG-107516>

TL;DR: I have nothing against *adding* Clang and I have no skin in the game 
for the binaries (I always tell people to NEVER use precompiled binaries 
anyway). So you have my full support, so long as GCC is still supported and 
tested in the CI. Oh well, I may support it myself, like I support FreeBSD/
Clang.

> For a while now we have a CI configuration testing with LLVM MinGW.
> 
> The benefits of the  LLVM MinGW<https://github.com/mstorsjo/llvm-mingw>
> would be (quote from the website):
> 
>   *   Support for targeting ARM/ARM64 (while GCC obviously does support
> these architectures, it doesn't support Windows on ARM) 

That's a new architecture and doesn't require replacing anything.

> *   A single toolchain targeting all four architectures (i686, x86_64, armv7 
and arm64) instead of separate compiler binaries for each architecture 

That's an interesting gain, but it's minor.

> *   Support for generating debug info in PDB format

How useful is this? Does gdb support this format? If not, then you wouldn't be 
able to debug stuff, meaning this is not a benefit at all.

>   *   Support for Address Sanitizer and Undefined Behaviour Sanitizer

This is good.

>   *   Since LLVM 16: Support for Control Flow Guard (-mguard=cf compile and
> link flags)

Is this useful?

Adding:
* Support for proper AVX without the hack in qsimd_p.h

> In the bug report I've tested also gdb 11.2.0 and lldb 16.0.6 with Qt
> Creator's source code and lldb was twice as fast at reaching the breakpoint
> (35s vs 1m14s).

In my experience, lldb is faster but has a worse interface, so I prefer to use 
GDB whenever I need to use it directly, instead of via Qt Creator. And 
debugging on Windows means "use directly" because Qt Creator doesn't support 
remote Windows environments.

> With this migration would should also switch to Universal
> CRT<https://devblogs.microsoft.com/cppblog/introducing-the-universal-crt/>.
> The toolchain comes in both ucrt and msvcrt variants, but the former is
> preferrable nowadays.

Indeed and that's great, but that's a BC break. That means you'll need to 
provide two sets of binaries for a time.

It's also orthogonal, because GCC supports UCRT too, with this patch:
https://github.com/msys2/MINGW-packages/raw/
8d9ebb74412c1faabc2a3935bfc705bec19edb9a/mingw-w64-gcc/0006-Windows-New-
feature-to-allow-overriding.patch

I haven't tried Qt with this, but I have my $DAYJOB software and it works 
great.

> At  Windows Runtime (WinRT) APIs support · Issue #307 · mstorsjo/llvm-mingw
> (github.com)<https://github.com/mstorsjo/llvm-mingw/issues/307> we can see
> that starting with LLVM 15 and with a recent release of
> C++/WinRT<https://github.com/microsoft/cppwinrt/releases> or
> mingw-w64-cppwinrt<https://github.com/alvinhochun/mingw-w64-cppwinrt/releas
> es/> we could have feature parity with the Visual C++ toolchain.

I need a little more background on this: what are these APIs useful for? What 
gets enabled when they are supported?

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Cloud Software Architect - Intel DCAI Cloud Engineering
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5152 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20230719/8c2cf5ef/attachment-0001.bin>