Re: [PATCH] gitlab: remove duplication between msys jobs

[Thomas Huth <thuth@redhat.com>]

On 28/07/2023 11.50, Thomas Huth wrote:
> On 28/07/2023 11.32, Marc-André Lureau wrote:
>> Hi
>>
>> On Fri, Jul 28, 2023 at 12:59 PM Daniel P. Berrangé <berrange@redhat.com> 
>> wrote:
>>>
>>> On Fri, Jul 28, 2023 at 10:35:35AM +0200, Thomas Huth wrote:
>>>> On 27/07/2023 12.39, Daniel P. Berrangé wrote:
>>>>> On Wed, Jul 26, 2023 at 08:21:33PM +0200, Thomas Huth wrote:
>>>>>> On 26/07/2023 18.19, Daniel P. Berrangé wrote:
>>>> ...
>>>>>> Anyway, before we unify the compiler package name suffix between the two
>>>>>> jobs, I really would like to see whether the mingw Clang builds QEMU 
>>>>>> faster
>>>>>> in the 64-bit job ... but so far I failed to convince meson to accept the
>>>>>> Clang from the mingw package ... does anybody know how to use Clang with
>>>>>> MSYS2 properly?
>>>>>
>>>>> AFAIK it shouldn't be anything worse than
>>>>>
>>>>>     CC=clang ./configure ....
>>>>>
>>>>> if that doesn't work then its a bug IMHO
>>>>
>>>> No, it's not that easy ... As Marc-André explained to me, MSYS2 maintains a
>>>> completely separate environment for Clang, i.e. you have to select this
>>>> different environment with $env:MSYSTEM = 'CLANG64' and then install the
>>>> packages that have the "mingw-w64-clang-x86_64-" prefix.
>>>>
>>>> After lots of trial and error, I was able to get a test build here:
>>>>
>>>>   https://gitlab.com/thuth/qemu/-/jobs/4758605925
>>>>
>>>> I had to disable Spice and use --disable-werror in that build to make it
>>>> succeed, but at least it shows that Clang seems to be a little bit faster -
>>>> the job finished in 58 minutes. So if we can get the warnings fixed, this
>>>> might be a solution for the timeouts here...
>>>
>>> Those packing warnings look pretty serious
>>>
>>> C:/GitLab-Runner/builds/thuth/qemu/include/block/nvme.h:1781:16: warning: 
>>> unknown attribute 'gcc_struct' ignored [-Wunknown-attributes]
>>>
>>> This means CLang is using the MSVC struct packing ABI for bitfields,
>>> which is different from the GCC struct packing ABI. If any of those
>>> structs use bitfields and are exposed as guest hardware ABI, or in
>>> migration vmstate, then this is potentially broken compilation.
>>>
>>
>> Yes .. gcc >=4.7 and clang >=12 have mms-bitfiles enabled by default,
>> but we can't undo that MS struct packing on clang apparently:
>> https://discourse.llvm.org/t/how-to-undo-the-effect-of-mms-bitfields/72271
> 
> I wonder whether we really still need the gcc_struct in QEMU...
> As far as I understand, this was mainly required for bitfields in packed 
> structs in the past

Ok, never mind, according to this post:

https://lists.gnu.org/archive/html/qemu-devel/2011-08/msg00964.html

this affects all structs, not only the ones with bitfieds.

And it seems like we also still have packed structs with bitfields in code 
base, see e.g. "struct ip" in net/util.h, so using Clang on Windows likely 
currently can't work?

  Thomas