[build] mingw-gcc14-git fails to build 32-bit dxvk 2.3 in src/d3d9/d3d9.dll.p/d3d9_mem.cpp.obj

[ms178]

Due to another issue with dxvk and mingw-gcc-13.2.1 (no DX apps work), I've decided to be brave, trying out a fresh mingw-gcc-git build from September 28th 2023. I saw the following build error in the 32-bit build with modest flags on my Haswell system. Maybe that's a pre-existing dxvk problem only revealed by the new compiler?! I've verified with mingw-gcc-12.3.1 that everything compiles fine with the old stable toolchain with the same dxvk version and compiler flags.

FAILED: src/d3d9/d3d9.dll.p/d3d9_mem.cpp.obj 
i686-w64-mingw32-g++ -Isrc/d3d9/d3d9.dll.p -Isrc/d3d9 -I../../dxvk/src/d3d9 -I../../dxvk/include -I../../dxvk/include/vulkan/include -I../../dxvk/include/spirv/include -fdiagnostics-color=always -DNDEBUG -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wextra -std=c++17 -O3 -msse -msse2 -msse3 -mfpmath=sse -Wimplicit-fallthrough -Wno-missing-field-initializers -Wno-unused-parameter -Wno-cast-function-type -Wno-unused-const-variable -Wno-missing-braces -DNOMINMAX -D_WIN32_WINNT=0xa00 -DDXVK_WSI_WIN32 -O3 -march=native -mtune=native -maes -mbmi2 -mpclmul -fno-semantic-interposition -flto=auto -fdevirtualize-at-ltrans -mharden-sls=none -MD -MQ src/d3d9/d3d9.dll.p/d3d9_mem.cpp.obj -MF src/d3d9/d3d9.dll.p/d3d9_mem.cpp.obj.d -o src/d3d9/d3d9.dll.p/d3d9_mem.cpp.obj -c ../../dxvk/src/d3d9/d3d9_mem.cpp
../../dxvk/src/d3d9/d3d9_mem.cpp: In element function »void dxvk::D3D9MemoryAllocator::FreeChunk(dxvk::D3D9MemoryChunk*)«:
../../dxvk/src/d3d9/d3d9_mem.cpp:52:25: error: »remove_if« is no element of »std«; did you mean »remove_cv«?
   52 |     m_chunks.erase(std::remove_if(m_chunks.begin(), m_chunks.end(), [&](auto& item) {
      |                         ^~~~~~~~~
      |                         remove_cv

[turol]

Does it work if you add

#include <algorithm>

to d3d9_mem.cpp?

dxvk/src/d3d9/d3d9_mem.cpp

Line 6 in 494f7fd

#include <utility>

[ms178]

Yes, that fixes that particular build error.

[ms178]

By the way, I still see the following build issue with LTO later on (which was also present in 13.2.1 on an earlier dxvk build):

FAILED: src/d3d11/d3d11.dll 
i686-w64-mingw32-g++  -o src/d3d11/d3d11.dll src/d3d11/d3d11.dll.p/version.o src/d3d11/d3d11.dll.p/.._dxgi_dxgi_format.cpp.obj src/d3d11/d3d11.dll.p/d3d11_annotation.cpp.obj src/d3d11/d3d11.dll.p/d3d11_blend.cpp.obj src/d3d11/d3d11.dll.p/d3d11_buffer.cpp.obj src/d3d11/d3d11.dll.p/d3d11_class_linkage.cpp.obj src/d3d11/d3d11.dll.p/d3d11_cmdlist.cpp.obj src/d3d11/d3d11.dll.p/d3d11_context.cpp.obj src/d3d11/d3d11.dll.p/d3d11_context_def.cpp.obj src/d3d11/d3d11.dll.p/d3d11_context_ext.cpp.obj src/d3d11/d3d11.dll.p/d3d11_context_imm.cpp.obj src/d3d11/d3d11.dll.p/d3d11_cuda.cpp.obj src/d3d11/d3d11.dll.p/d3d11_depth_stencil.cpp.obj src/d3d11/d3d11.dll.p/d3d11_device.cpp.obj src/d3d11/d3d11.dll.p/d3d11_enums.cpp.obj src/d3d11/d3d11.dll.p/d3d11_features.cpp.obj src/d3d11/d3d11.dll.p/d3d11_fence.cpp.obj src/d3d11/d3d11.dll.p/d3d11_gdi.cpp.obj src/d3d11/d3d11.dll.p/d3d11_initializer.cpp.obj src/d3d11/d3d11.dll.p/d3d11_input_layout.cpp.obj src/d3d11/d3d11.dll.p/d3d11_interop.cpp.obj src/d3d11/d3d11.dll.p/d3d11_main.cpp.obj src/d3d11/d3d11.dll.p/d3d11_on_12.cpp.obj src/d3d11/d3d11.dll.p/d3d11_options.cpp.obj src/d3d11/d3d11.dll.p/d3d11_query.cpp.obj src/d3d11/d3d11.dll.p/d3d11_rasterizer.cpp.obj src/d3d11/d3d11.dll.p/d3d11_resource.cpp.obj src/d3d11/d3d11.dll.p/d3d11_sampler.cpp.obj src/d3d11/d3d11.dll.p/d3d11_shader.cpp.obj src/d3d11/d3d11.dll.p/d3d11_state.cpp.obj src/d3d11/d3d11.dll.p/d3d11_state_object.cpp.obj src/d3d11/d3d11.dll.p/d3d11_swapchain.cpp.obj src/d3d11/d3d11.dll.p/d3d11_texture.cpp.obj src/d3d11/d3d11.dll.p/d3d11_util.cpp.obj src/d3d11/d3d11.dll.p/d3d11_video.cpp.obj src/d3d11/d3d11.dll.p/d3d11_view_dsv.cpp.obj src/d3d11/d3d11.dll.p/d3d11_view_rtv.cpp.obj src/d3d11/d3d11.dll.p/d3d11_view_srv.cpp.obj src/d3d11/d3d11.dll.p/d3d11_view_uav.cpp.obj src/d3d11/d3d11.dll.p/.._d3d10_d3d10_blend.cpp.obj src/d3d11/d3d11.dll.p/.._d3d10_d3d10_buffer.cpp.obj src/d3d11/d3d11.dll.p/.._d3d10_d3d10_depth_stencil.cpp.obj src/d3d11/d3d11.dll.p/.._d3d10_d3d10_device.cpp.obj src/d3d11/d3d11.dll.p/.._d3d10_d3d10_input_layout.cpp.obj src/d3d11/d3d11.dll.p/.._d3d10_d3d10_multithread.cpp.obj src/d3d11/d3d11.dll.p/.._d3d10_d3d10_query.cpp.obj src/d3d11/d3d11.dll.p/.._d3d10_d3d10_rasterizer.cpp.obj src/d3d11/d3d11.dll.p/.._d3d10_d3d10_sampler.cpp.obj src/d3d11/d3d11.dll.p/.._d3d10_d3d10_texture.cpp.obj src/d3d11/d3d11.dll.p/.._d3d10_d3d10_util.cpp.obj src/d3d11/d3d11.dll.p/.._d3d10_d3d10_view_dsv.cpp.obj src/d3d11/d3d11.dll.p/.._d3d10_d3d10_view_rtv.cpp.obj src/d3d11/d3d11.dll.p/.._d3d10_d3d10_view_srv.cpp.obj -Wl,--allow-shlib-undefined -Wl,-O1 -shared ../../dxvk/src/d3d11/d3d11.def -Wl,--start-group -Wl,--out-implib=src/d3d11/d3d11.dll.a -static -static-libgcc -static-libstdc++ -Wl,--file-alignment=4096 -Wl,--enable-stdcall-fixup -Wl,--kill-at -Wl,-O3,--as-needed,-Bsymbolic-functions,--sort-common,-flto=auto -Wl,--gc-sections -march=native -mtune=native -maes -mbmi2 -mpclmul src/dxbc/libdxbc.a src/dxvk/libdxvk.a src/util/libutil.a src/spirv/libspirv.a src/wsi/libwsi.a subprojects/libdisplay-info/libdisplay-info.a src/vulkan/libvkcommon.a -ldxgi -pthread -lm -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 -Wl,--end-group
../../dxvk/src/d3d11/d3d11_buffer.cpp: In function 'bool dxvk::CheckViewCompatibility(const DxvkBufferViewCreateInfo&, const DxvkBufferViewCreateInfo&)':
../../dxvk/src/d3d11/d3d11_buffer.cpp:206:3: error: no register to spill
  206 |   }
      |   ^
../../dxvk/src/d3d11/d3d11_buffer.cpp:206:3: error: this is the insn:
(insn 203 219 220 17 (parallel [
            (set (reg:DI 153 [142])
                (and:DI (not:DI (reg:DI 152))
                    (reg/v:DI 151 [orig:96 features ] [96])))
            (clobber (reg:CC 17 flags))
        ]) "../../dxvk/src/d3d11/d3d11_buffer.cpp":294:40 481 {*andndi3_doubleword_bmi}
     (expr_list:REG_DEAD (reg:DI 152)
        (expr_list:REG_DEAD (reg/v:DI 151 [orig:96 features ] [96])
            (expr_list:REG_UNUSED (reg:CC 17 flags)
                (nil)))))
../../dxvk/src/d3d11/d3d11_buffer.cpp:206: confused by earlier errors, bailing out

[turol]

That is an Internal Compiler Error. It's a bug in GCC and should be reported to them.

[ms178]

Thanks, I should add a bit more context: Your fix unblocked me getting proton-cachyos to compile with mingw-gcc14-git; however the final dxvk binary still doesn't seem to work with several tested DX11 titles that crash at startup (e.g. Battlefield 1). This was also the case with minw-gcc-13.2.1; I also use quite aggressive compiler flags.

I can get it working again by exchanging the dxvk files under /usr/share/steam/proton with dxvk binaries compiled with mingw-gcc12.3.1 which I produce with a specific dxvk-mingw PKGBUILD. This way I get the best of the old and the new toolchain and get the DX11 titles working again.

As mingw-gcc is still at 12 on Arch Linux, most people compiling from source won't see this issue until Arch upgrades its mingw toolchain.

[Blisto91]

@ms178 Are you still having issues with this?

[ms178]

@ms178 Are you still having issues with this?

I haven't used mingw-gcc-14-git for a while. I also saw other issues with the stable GCC-14 release and the current MinGW version that made me abandon that GCC revision alltogether as it probably needs some more work from the MinGW side. However, using a recent mingw-gcc-13 snapshot some weeks ago, I still saw problems with DXVK in general using my aggressive flags that used to work with 12.3.1 which lead to non-starting or exciting DX games. But that is a different issue from the one originally reported here and probably not worth investigating at the moment.

Due to a recent switch in hardware, I am also not on Linux at the moment to investigate further.

[aur-r]

I was about to fill a new bug report when I saw this one.
On my system, after a recent update of mingw-gcc to 14.1.1 dxvk also fails to compile while with mingw-gcc 13.2.1 worked without issues.
mingw-gcc versions:
x86_64-w64-mingw32-gcc (gcc 14.1.1 "x86_64-w64-mingw32-gcc (GCC) 14.1.1 20240607 (Mageia MinGW 14.1.1-1.mga10)
x86_64-w64-mingw32-gcc (gcc 13.2.1 "x86_64-w64-mingw32-gcc (GCC) 13.2.1 20230728 (Mageia MinGW 13.2.1-1.mga10)

Including <algorithm> into any of d3d9_mem.(h,cpp) files fixed it for me.

It looks like <algorithm> is also included into src/dxvk/dxvk_memory.cpp, src/dxvk/dxvk_presenter.cpp which use remove_if too, so, at least for consistency sake, d3d9_mem should include algorithm imo.

Besides this minor issue building/running dxvk with mingw-gcc-14.1.1 looks fine in my case.
Regards.

[Blisto91]

Fixed with 38308d4