Compile errors on gcc 10.1

dxvkclosed

doitsujin/dxvk#1620 · opened 2020-05-09 by lacc97 · updated 2020-12-31 · 7 comments · github

Llacc97 2020-05-09 github

After upgrading mingw-gcc to 10.1.0 on Gentoo, 32-bit dxvk on master fails to compile:
build.log

Errors are all of the type

../src/util/com/../../d3d11/../dxgi/../dxvk/../vulkan/vulkan_loader.h:64:15: error: field ‘vkCreateInstance’ has incomplete type ‘dxvk::vk::VulkanFn<VkResult (__attribute__((stdcall)) *)(const VkInstanceCreateInfo*, const VkAllocationCallbacks*, VkInstance_T**)>’
   64 |     VULKAN_FN(vkCreateInstance);
      |               ^~~~~~~~~~~~~~~~
../src/util/com/../../d3d11/../dxgi/../dxvk/../vulkan/vulkan_loader_fn.h:22:28: note: in definition of macro ‘VULKAN_FN’
   22 |   VulkanFn<::PFN_ ## name> name = sym(#name)
      |                            ^~~~
../src/util/com/../../d3d11/../dxgi/../dxvk/../vulkan/vulkan_loader_fn.h:27:9: note: declaration of ‘class dxvk::vk::VulkanFn<VkResult (__attribute__((stdcall)) *)(const VkInstanceCreateInfo*, const VkAllocationCallbacks*, VkInstance_T**)>’
   27 |   class VulkanFn;
      |         ^~~~~~~~

so the problem seems to be that for some reason gcc doesn't select the correct template specialization for the Vulkan API function pointer types.

Reading through the gcc-10 changelog and porting notes, I don't see any reason why this code should fail to compile on gcc-10 but not on gcc-9, so maybe this is a gcc regression?

I had no problems compiling 64-bit dxvk.

Ddoitsujin maintainer 2020-05-09 github

Feel free to PR a fix. mingw isn't shipping gcc 10 yet so I can't really test that at the moment.

I don't think this is a GCC bug but rather a problem with the template specialization being wrong, but it's weird that this hasn't been causing issues so far on any compiler, including GCC, MSVC, and Clang.

Mmisyltoad 2020-05-09 github

Doing a 32-bit build of dxvk-native with GCC 10.1 from Arch Linux staging repos works fine here.

(meson --cross-file /usr/share/meson/cross/x86-linux-gnu build)

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/10.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --with-isl --with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit --enable-cet=auto --enable-checking=release --enable-clocale=gnu --enable-default-pie --enable-default-ssp --enable-gnu-indirect-function --enable-gnu-unique-object --enable-install-libiberty --enable-linker-build-id --enable-lto --enable-multilib --enable-plugin --enable-shared --enable-threads=posix --disable-libssp --disable-libstdcxx-pch --disable-libunwind-exceptions --disable-werror gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.1.0 (GCC)```

Ddoitsujin maintainer 2020-05-09 github

@lacc97 actually can you test this: https://github.com/doitsujin/dxvk/tree/build-fix

Still no idea why the current code would fail, but if that branch works, I'll just pull that in.

Llacc97 2020-05-09 github

Compilation works for me now on that branch, both 32-bit and 64-bit dxvk.

Yeah, it's an odd bug. It may something Gentoo-specific.

Ddoitsujin maintainer 2020-05-10 github

Thanks for confirming, merged the fix.

FFireBurn 2020-05-16 github

I think its related to winelib builds, this is what I'm seeing:

FAILED: src/vulkan/67fefa6@@vkcommon@sta/vulkan_loader.cpp.o
wineg++ -Isrc/vulkan/67fefa6@@vkcommon@sta -Isrc/vulkan -I../dxvk-1.7/src/vulkan -I../dxvk-1.7/include -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -std=c++17 -DNOMINMAX --no-gnu-unique -O3 -m32 -msse -msse2 -fvisibility=hidden -fvisibility-inlines-hidden -D__WIDL_objidl_generated_name_0000000C= -fPIC -pthread -MD -MQ 'src/vulkan/67fefa6@@vkcommon@sta/vulkan_loader.cpp.o' -MF 'src/vulkan/67fefa6@@vkcommon@sta/vulkan_loader.cpp.o.d' -o 'src/vulkan/67fefa6@@vkcommon@sta/vulkan_loader.cpp.o' -c ../dxvk-1.7/src/vulkan/vulkan_loader.cpp
../dxvk-1.7/src/vulkan/vulkan_loader.cpp:9:64: error: invalid conversion from ‘void (attribute((stdcall)) * ()(VkInstance, const char))()’ {aka ‘void (attribute((stdcall)) * ()(VkInstance_T, const char*))()’} to ‘PFN_vkGetInstanceProcAddr’ {aka ‘void (attribute((stdcall)) * (attribute((stdcall)) )(VkInstance_T, const char*))()’} [-fpermissive]
9 | static const PFN_vkGetInstanceProcAddr GetInstanceProcAddr = native_vkGetInstanceProcAddrWINE;
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| |
| void (attribute((stdcall)) * ()(VkInstance, const char))() {aka void (attribute((stdcall)) * ()(VkInstance_T, const char*))()}
winegcc: /usr/bin/x86_64-pc-linux-gnu-g++ failed

Reverting your removal allows 1.7 to be built and work with winelib, just passing -fpermissive stops a few things from working

RRadamant319 2020-12-31 github

I compiled dxvk-1.7.3 with gcc 10.2. on Debian Bullseye. I had to use following update alternatives:

sudo update-alternatives --config i686-w64-mingw32-gcc
sudo update-alternatives --config i686-w64-mingw32-g++
sudo update-alternatives --config x86_64-w64-mingw32-gcc
sudo update-alternatives --config x86_64-w64-mingw32-g++

and i built dxvk manually.

./package-release.sh master /your/target/directory --no-package works too.

Though dxvk-1.7.3 is ok.

Nothing extracted yet.