Re: [PATCH] Fix ARM64/MSVC atomic memory ordering issues on Win11 by adding explicit DMB ​barriers

On Nov 23 2025, at 3:32 pm, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:

> On Mon, Nov 24, 2025 at 4:55 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
>> > - if cc.links(prog, name: '__crc32cb, __crc32ch, __crc32cw, and
>> __crc32cd without -march=armv8-a+crc',
>> > + if cc.get_id() == 'msvc'
>> > + cdata.set('USE_ARMV8_CRC32C', 1)
>> > + have_optimized_crc = true
>>
>> Should have a comment explaining why we can do this unconditionally...
>
> I was wondering about that in light of your revelation that it must be
> using /arch:armv8.0 by default. If we only support Windows/ARM on
> armv8.1 hardware (like Windows 11 itself), then I think that means
> that we'd want /arch:armv8.1 here:
>
> + # Add ARM64 architecture flag for Windows 11 ARM64 for correct intrensics
> + if host_machine.system() == 'windows' and host_machine.cpu_family()
> == 'aarch64'
> + add_project_arguments('/arch:armv9.4', language: ['c', 'cpp'])
> + endif

Hey Thomas,

Turns out that flag isn't required at all, the issue was the S_UNLOCK()
implementation's use of a compiler barrier not a CPU memory barrier.

> We can't impose our own random high ISA requirement like that, or some
> machines will choke on illegal instructions.

New incoming patch drops this entirely, so no need to worry about it.

> I wonder if the same applies to Visual Studio on x86. The OS now
> requires x86-64-v2 (like RHEL9, and many other Linux distros except
> Debian?), but Visual Studio might not know that... but then we might
> say that's an issue for the EDB packaging crew to think about, not us.
>
> In that case we might want to say "OK you choose the ARM version, but
> we're not going to write the runtime test for CRC on armv8, we'll do a
> compile-time test only, because it would be stupid to waste time
> writing code for armv8.0".

best.

-greg