Undeclared identifier atomicStoreN when cross-compiling to Windows with ORC and threads

[jrfondren]

Description

With Zig as a cross-compiler with zigcc.sh:

#! /bin/bash
exec zig cc --target=$ZIGTARGET "$@"

A Nim 'hello world' ...

echo "hello world"

fails to cross-compile to Windows with --mm:orc.

Nim Version

Nim Compiler Version 2.0.0 [MacOSX: arm64]
Compiled at 2023-08-04
Copyright (c) 2006-2023 by Andreas Rumpf

Current Output

% ZIGTARGET=x86_64-windows CC=$PWD/zigcc.sh nim c --cc:env -d:release --mm:orc --os:windows --cpu:amd64 hello.nim
Hint: used config file '/Users/jfondren/nim/nim-2.0.0/config/nim.cfg' [Conf]
Hint: used config file '/Users/jfondren/nim/nim-2.0.0/config/config.nims' [Conf]
.........................................................
/Users/jfondren/nim/nim-2.0.0/lib/system/alloc.nim(776, 5) template/generic instantiation of `atomicPrepend` from here
/Users/jfondren/nim/nim-2.0.0/lib/system/alloc.nim(767, 18) template/generic instantiation of `storea` from here
/Users/jfondren/nim/nim-2.0.0/lib/system/alloc.nim(140, 36) Error: undeclared identifier: 'atomicStoreN'
candidates (edit distance, scope distance); see '--spellSuggest':
 (4, 3): 'atomicStatDec'
 (4, 3): 'atomicStatInc'

Possible Solution

Compilation succeeds with either --threads:off or --mm:refc

Additional Information

This might be similar to #20873

[Araq]

We don't support Zig though.

[jrfondren]

It's just clang properly set up as a cross-compiler for that target. Without it I can't demonstrate the bug as basic headers like windows.h aren't available on my system.

As tooling, Zig makes Nim very competitive against go. Go has static binaries on Linux but I don't need them when I can target the exact glibc version I need. Go also doesn't need any more work than GOOS= GOARCH= settings to cross-compile to Windows, but Nim binaries are much smaller (in one case, 8G vs. <300k) and the language is of course much nicer. It's nice to not need old server images just to build sufficiently portable executables.

[Araq]

Off topic, but how can Go be "competitive" when it produces a 8G binary? No, don't answer the question! The point is that this perspective is rather foolish. The number of users who migrate from Go to Nim is close to zero, no matter how "competitive" Nim is and that's fine, Go is not "competitive" against Haskell and Ocaml either, but nobody noticed.

[ringabout]

Btw, -d:useMalloc might work.

[Wh1teDuke]

--cc:tcc yields the same issue, but -d:useMalloc fixed it.