December 2025 - Wine-GitLab

[PATCH v4 0/3] MR9755: mfmediaengine fixes
by Matteo Bruni (＠Mystral) Dec. 15, 2025

Dec. 15, 2025

Fixes for regression bug 59047 -- v4: mfmediaengine/tests: Test WASAPI audio session interaction. https://gitlab.winehq.org/wine/wine/-/merge_requests/9755

2 3

[PATCH v2 0/5] MR9749: mmdevapi: Reject wave formats that crash audio drivers.
by Giovanni Mascellani (＠giomasce) Dec. 15, 2025

Dec. 15, 2025

I am working on a overhaul of how mmdevapi should behave when given invalid or borderline wave formats. In some cases that leads to a crash, which I suppose is appropriate to fix even during the freeze. So here it is. I'm pretty sure that the OSS backend suffers from the same problem. I could write a patch and check that it builds, but have no way to test it. Should I submit it anyway? -- v2: winealsa.drv: Avoid a division by zero. winepulse.drv: Avoid a division by zero. winecoreaudio.drv: Avoid a division by zero. mmdevapi: Reject wave formats with zero block alignment. https://gitlab.winehq.org/wine/wine/-/merge_requests/9749

2 5

[PATCH v21 0/17] MR7111: support building Wine with LTO
by Konstantin Demin (＠rockdrilla) Dec. 14, 2025

Dec. 14, 2025

relevant bug reports: - https://bugs.winehq.org/show_bug.cgi?id=41712 - https://bugs.winehq.org/show_bug.cgi?id=51051 -- v21: ntoskrnl: move i386 specific Rtl*ByteSwap() into separate source. ntoskrnl: move _chkstk() / __chkstk() into separate source. msvcrt: move i386 specific _ftol() into separate source. kernel32: move x86-64 specific GetProcAddress() into separate source. kernel32: move i386 specific Interlocked*() into separate source. kernel32: move i386 specific ExitProcess() into separate source. kernelbase: move x86-64 specific GetProcAddress() into separate source. ntdll: move i386 specific Rtl*ByteSwap() into separate source. tools: add LTO quirks. makedep: support skipping/disabling LTO. configure: enable building Wine with LTO. makedep: support LTO builds. winegcc: support LTO builds. winebuild: support LTO builds. tools: helper functions for LTO builds. ntdll: add attribute "used" to a few symbols that should not be discarded. loader: add attribute "used" to a few symbols that should not be discarded. This merge request has too many patches to be relayed via email. Please visit the URL below to see the contents of the merge request. https://gitlab.winehq.org/wine/wine/-/merge_requests/7111

3 6

[PATCH 0/2] MR9767: Add a missing period in urlmon and update Simplified Chinese translation.
by Jactry Zeng (＠jactry) Dec. 14, 2025

Dec. 14, 2025

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/9767

2 2

[PATCH 0/3] MR9766: include: Add ID3D12VideoProcessor in d3d12video.idl.
by Biswapriyo Nath (＠Biswa96) Dec. 14, 2025

Dec. 14, 2025

Requied for https://github.com/FFmpeg/FFmpeg/commit/c4d22f2d2c27ca6a078c126fbd371ded47b… -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9766

2 3

Re: [PATCH v2 0/1] MR9762: msvcrt: Rename __C_specific_handler to avoid a clang20 crash
by Jacek Caban (＠jacek) Dec. 13, 2025

Dec. 13, 2025

On Sat Dec 13 21:47:56 2025 +0000, Martin Storsjö wrote: > Thanks; with that (with a simplified command line `clang -target > arm64ec-windows-msvc repro.c -c -fasync-exceptions`) was able to bisect > that the crash was fixed in https://github.com/llvm/llvm-project/commit/8eba02288634e5b14f5d2a13763ddfd…. > I don't entirely understand all aspects of the crash (I guess @jacek may > know more), but I guess this workaround should be quite safe in any case. Thanks for those findings! I guess it was not a problem until I enabled compiler exceptions in !8112. I think we could just disable that for Clang versions older than 21 on ARM64EC in except.h. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9762#note_125581

1 0

Re: [PATCH v2 0/1] MR9762: msvcrt: Rename __C_specific_handler to avoid a clang20 crash
by Martin Storsjö Dec. 13, 2025

Dec. 13, 2025

On Sat Dec 13 15:00:12 2025 +0000, André Zwing wrote: > crashes for clang19 and clang20: > `clang "-cc1" "-triple" "arm64ec-unknown-windows-msvc19.33.0" > "-emit-obj" "-fms-extensions" "-fasync-exceptions" except-3d067c.c` Thanks; with that (with a simplified command line `clang -target arm64ec-windows-msvc repro.c -c -fasync-exceptions`) was able to bisect that the crash was fixed in https://github.com/llvm/llvm-project/commit/8eba02288634e5b14f5d2a13763ddfd…. I don't entirely understand all aspects of the crash (I guess @jacek may know more), but I guess this workaround should be quite safe in any case. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9762#note_125579

1 0

[PATCH v2 0/2] MR9722: windowscodecs: Support trivial cases for copying 1bpp indexed data.
by Dmitry Timoshkov (＠dmitry) Dec. 13, 2025

Dec. 13, 2025

-- v2: windowscodecs: Remove optimization for 1bpp pixel formats from WICConvertBitmapSource(). windowscodecs: Support trivial cases for copying 1bpp indexed data. https://gitlab.winehq.org/wine/wine/-/merge_requests/9722

3 3

[PATCH v2 0/1] MR9764: msi/tests: Fix some typos (Coverity).
by Sven Baars (＠sbaars) Dec. 13, 2025

Dec. 13, 2025

-- v2: msi/tests: Fix some typos (Coverity). https://gitlab.winehq.org/wine/wine/-/merge_requests/9764

2 1

Re: [PATCH v2 0/1] MR9762: msvcrt: Rename __C_specific_handler to avoid a clang20 crash
by André Zwing Dec. 13, 2025

Dec. 13, 2025

On Fri Dec 12 23:17:09 2025 +0000, André Zwing wrote: > with creduce I was able to get this to crash: > ``` > #define a(b, c) __except (b()) > long d() { > __try { > } > a(d, ) {} > } > void __C_specific_handler() {} > ``` > the define is __EXCEPT_CTX > it crashes for me on x86_64 and on ARM64: > `"/mnt/nvme/llvm-mingw-20250305-ucrt-ubuntu-20.04-aarch64/bin/clang-20" > "-cc1" "-triple" "arm64ec-unknown-windows-msvc19.33.0" "-emit-obj" > "-mincremental-linker-compatible" "-disable-free" > "-clear-ast-before-backend" "-disable-llvm-verifier" > "-discard-value-names" "-main-file-name" "except.c" "-mrelocation-model" > "pic" "-pic-level" "2" "-mframe-pointer=none" "-relaxed-aliasing" > "-fmath-errno" "-ffp-contract=on" "-fno-rounding-math" > "-ffp-exception-behavior=maytrap" "-mconstructor-aliases" > "-funwind-tables=2" "-target-cpu" "generic" "-target-feature" "+v8a" > "-target-feature" "+fp-armv8" "-target-feature" "+neon" "-target-abi" > "aapcs" "-debug-info-kind=constructor" "-dwarf-version=4" > "-ffunction-sections" "-D" "__STDC__" "-D" "_MSVCR_VER=0" "-D" > "__WINESRC__" "-D" "_CRTDLL" "-D" "_CRTIMP=" "-D" "__WINE_PE_BUILD" > "-O2" "-Wall" "-Wdeclaration-after-statement" "-Wempty-body" > "-Wignored-qualifiers" "-Winit-self" > "-Wno-microsoft-enum-forward-reference" "-Wstrict-prototypes" > "-Wtype-limits" "-Wunused-but-set-parameter" "-Wvla" "-Wwrite-strings" > "-Wpointer-arith" "-Wabsolute-value" "-fconst-strings" "-ferror-limit" > "19" "-fno-builtin" "-fno-use-cxa-atexit" "-fms-extensions" > "-fms-compatibility" "-fms-compatibility-version=19.33" > "-fskip-odr-check-in-gmf" "-fdelayed-template-parsing" > "-fasync-exceptions" "-fexceptions" "-fcolor-diagnostics" > "-vectorize-loops" "-vectorize-slp" "-target-feature" "-fmv" "-faddrsig" > "-x" "c" "except-3d067c.c" ` > clang21 works fine > the native ubuntu clang20 also crashes, so it's not related to llvm-mingw crashes for clang19 and clang20: `clang "-cc1" "-triple" "arm64ec-unknown-windows-msvc19.33.0" "-emit-obj" "-fms-extensions" "-fasync-exceptions" except-3d067c.c` -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9762#note_125568

1 0