`core0.test_dlmalloc_inline` regression

[juj]

Something all my bots are currently hitting, which I first thought was an out-of-date cache or an out-of-date incremental LLVM build.. but is now persisting after a full clean, is

C:\emsdk\emscripten\main>test\runner test_dlmalloc_inline
Running 1 tests
[1/1] test_dlmalloc_inline (test_core.core0.test_dlmalloc_inline) ... FAIL

Stdout:
src.c:887:50: error: alias and aliasee have different types 'void *(size_t)' (aka 'void *(unsigned long)') and 'void *(size_t, size_t)' (aka 'void *(unsigned long, unsigned long)') [-Werror,-Wattribute-alias]
  887 | void* __libc_calloc(size_t) __attribute__((weak, alias("dlcalloc")));
      |                                                  ^
src.c:4885:7: note: aliasee is declared here
 4885 | void* dlcalloc(size_t n_elements, size_t elem_size) {
      |       ^
src.c:906:61: error: alias and aliasee have different types 'size_t (const void *)' (aka 'unsigned long (const void *)') and 'size_t (void *)' (aka 'unsigned long (void *)') [-Werror,-Wattribute-alias]
  906 | size_t malloc_usable_size(const void*) __attribute__((weak, alias("dlmalloc_usable_size")));
      |                                                             ^
src.c:5486:8: note: aliasee is declared here
 5486 | size_t dlmalloc_usable_size(void* mem) {
      |        ^
2 errors generated.
emcc: error: ''C:/emsdk/llvm/git/build_main_vs2022_64/Release/bin\clang.exe' -target wasm32-unknown-emscripten -fignore-exceptions -mllvm -combiner-global-alias-analysis=false -mllvm -enable-emscripten-sjlj -mllvm -disable-lsr '--sysroot=C:\emsdk\emscripten\main\cache\sysroot' -Xclang '-iwithsysroot/include\fakesdl' -Xclang '-iwithsysroot/include\compat' -Werror -O0 -c src.c -o 'C:\Users\clb\AppData\Local\Temp\emscripten_temp_nej_e824\src.o'' failed (returned 1)

None


======================================================================
FAIL: test_dlmalloc_inline (test_core.core0.test_dlmalloc_inline)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\emsdk\emscripten\main\test\common.py", line 1211, in run_process
    rtn = utils.run_process(cmd, check=check, **kwargs)
  File "C:\emsdk\emscripten\main\tools\utils.py", line 45, in run_process
    ret = subprocess.run(cmd, check=check, input=input, *args, **kw)
  File "C:\emsdk\python\3.13.3_64bit\Lib\subprocess.py", line 577, in run
    raise CalledProcessError(retcode, process.args,
                             output=stdout, stderr=stderr)
subprocess.CalledProcessError: Command '['C:\\emsdk\\emscripten\\main\\emcc.bat', 'src.c', '-o', 'src.js', '-sNO_DEFAULT_TO_CXX', '-sINITIAL_MEMORY=128mb', '-Wclosure', '-Werror', '-Wno-limited-postlink-optimizations', '-O0']' returned non-zero exit status 1.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "C:\emsdk\emscripten\main\test\test_core.py", line 338, in decorated
    return func(self, *args, **kwargs)
  File "C:\emsdk\emscripten\main\test\test_core.py", line 353, in decorated
    return func(self, *args, **kwargs)
  File "C:\emsdk\emscripten\main\test\test_core.py", line 6479, in test_dlmalloc_inline
    self.do_run(src, '*1,0*', args=['200', '1'], force_c=True)
    ~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\emsdk\emscripten\main\test\common.py", line 1389, in do_run
    return self._build_and_run(filename, expected_output, **kwargs)
           ~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\emsdk\emscripten\main\test\common.py", line 1421, in _build_and_run
    js_file = self.build(filename, **kwargs)
  File "C:\emsdk\emscripten\main\test\common.py", line 911, in build
    self.run_process(cmd, stderr=self.stderr_redirect if not DEBUG else None)
    ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "C:\emsdk\emscripten\main\test\common.py", line 1216, in run_process
    self.fail(f'subprocess exited with non-zero return code({e.returncode}): `{shlex.join(cmd)}`')
    ~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: subprocess exited with non-zero return code(1): `'C:\emsdk\emscripten\main\emcc.bat' src.c -o src.js -sNO_DEFAULT_TO_CXX -sINITIAL_MEMORY=128mb -Wclosure -Werror -Wno-limited-postlink-optimizations -O0`

Stdout:
src.c:887:50: error: alias and aliasee have different types 'void *(size_t)' (aka 'void *(unsigned long)') and 'void *(size_t, size_t)' (aka 'void *(unsigned long, unsigned long)') [-Werror,-Wattribute-alias]
  887 | void* __libc_calloc(size_t) __attribute__((weak, alias("dlcalloc")));
      |                                                  ^
src.c:4885:7: note: aliasee is declared here
 4885 | void* dlcalloc(size_t n_elements, size_t elem_size) {
      |       ^
src.c:906:61: error: alias and aliasee have different types 'size_t (const void *)' (aka 'unsigned long (const void *)') and 'size_t (void *)' (aka 'unsigned long (void *)') [-Werror,-Wattribute-alias]
  906 | size_t malloc_usable_size(const void*) __attribute__((weak, alias("dlmalloc_usable_size")));
      |                                                             ^
src.c:5486:8: note: aliasee is declared here
 5486 | size_t dlmalloc_usable_size(void* mem) {
      |        ^
2 errors generated.
emcc: error: ''C:/emsdk/llvm/git/build_main_vs2022_64/Release/bin\clang.exe' -target wasm32-unknown-emscripten -fignore-exceptions -mllvm -combiner-global-alias-analysis=false -mllvm -enable-emscripten-sjlj -mllvm -disable-lsr '--sysroot=C:\emsdk\emscripten\main\cache\sysroot' -Xclang '-iwithsysroot/include\fakesdl' -Xclang '-iwithsysroot/include\compat' -Werror -O0 -c src.c -o 'C:\Users\clb\AppData\Local\Temp\emscripten_temp_nej_e824\src.o'' failed (returned 1)

None

----------------------------------------------------------------------
Ran 1 test in 0.441s

FAILED (failures=1)

Oddly, I was not getting this failure on my Windows dev PC at first, until I updated LLVM build to latest (with emsdk install sdk-main-64bit to compile LLVM from source). So this suggests this would be some kind of an issue on LLVM side?

The errors look valid though - so maybe a new diagnostics item has been added to LLVM? Or I wonder if I've still got something stale.

[sbc100]

Yes, this is due to an LLVM change. There is proposed fix and discussion in #26934