Fedora Account System
Red Hat Associate
Red Hat Customer
Can not build vulkan-validation-layers v1.4.341.0 in Fedora Rawhide or Fedora 43 on aarch64. I disabled LTO and _annotated_builds to make sure it wasn't a plugin issue with: ``` %global _lto_cflags %nil %undefine _annotated_build ``` And the problem persists. Trace of the issue: ``` [ 10%] Building CXX object layers/CMakeFiles/VkLayer_utils.dir/vk_layer_config.cpp.o cd /builddir/build/BUILD/vulkan-validation-layers-1.4.341.0-build/Vulkan-ValidationLayers-vulkan-sdk-1.4.341.0/redhat-linux-build/layers && /usr/bin/g++ -DVK_ENABLE_BETA_EXTENSIONS -DVK_USE_PLATFORM_WAYLAND_KHR -DVK_USE_PLATFORM_XCB_KHR -DVK_USE_PLATFORM_XLIB_KHR -DVK_USE_PLATFORM_XLIB_XRANDR_EXT -I/builddir/build/BUILD/vulkan-validation-layers-1.4.341.0-build/Vulkan-ValidationLayers-vulkan-sdk-1.4.341.0/layers/. -I/builddir/build/BUILD/vulkan-validation-layers-1.4.341.0-build/Vulkan-ValidationLayers-vulkan-sdk-1.4.341.0/layers/vulkan -isystem /builddir/build/BUILD/vulkan-validation-layers-1.4.341.0-build/Vulkan-ValidationLayers-vulkan-sdk-1.4.341.0/layers/external -O1 -fexceptions -g1 -grecord-gcc-switches -pipe -Wall -Wno-complain-wrong-lang -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -mbranch-protection=standard -fasynchronous-unwind-tables -fstack-clash-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -DNDEBUG -std=c++17 -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -Wall -Wextra -Wpointer-arith -MD -MT layers/CMakeFiles/VkLayer_utils.dir/vk_layer_config.cpp.o -MF CMakeFiles/VkLayer_utils.dir/vk_layer_config.cpp.o.d -o CMakeFiles/VkLayer_utils.dir/vk_layer_config.cpp.o -c /builddir/build/BUILD/vulkan-validation-layers-1.4.341.0-build/Vulkan-ValidationLayers-vulkan-sdk-1.4.341.0/layers/vk_layer_config.cpp during RTL pass: expand In file included from /builddir/build/BUILD/vulkan-validation-layers-1.4.341.0-build/Vulkan-ValidationLayers-vulkan-sdk-1.4.341.0/layers/utils/hash_util.cpp:26: In function ‘XXH64_hash_t XXH3_len_0to16_64b(const xxh_u8*, size_t, const xxh_u8*, XXH64_hash_t)’, inlined from ‘XXH64_hash_t XXH3_64bits_internal(const void*, size_t, XXH64_hash_t, const void*, size_t, XXH3_hashLong64_f)’ at /builddir/build/BUILD/vulkan-validation-layers-1.4.341.0-build/Vulkan-ValidationLayers-vulkan-sdk-1.4.341.0/layers/./external/xxhash.h:6414:34, inlined from ‘XXH64_hash_t XXH3_64bits(const void*, size_t)’ at /builddir/build/BUILD/vulkan-validation-layers-1.4.341.0-build/Vulkan-ValidationLayers-vulkan-sdk-1.4.341.0/layers/./external/xxhash.h:6428:32: /builddir/build/BUILD/vulkan-validation-layers-1.4.341.0-build/Vulkan-ValidationLayers-vulkan-sdk-1.4.341.0/layers/./external/xxhash.h:4733:31: internal compiler error: in aarch64_function_arg_alignment, at config/aarch64/aarch64.cc:6969 4733 | return XXH64_avalanche(seed ^ (XXH_readLE64(secret+56) ^ XXH_readLE64(secret+64))); | ~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Please submit a full bug report, with preprocessed source. See <https://bugzilla.redhat.com/> for instructions. Preprocessed source stored into /tmp/ccASsMOB.out file, please attach this to your bugreport. ``` Links to the jobs that failed: - Rawhide: https://koji.fedoraproject.org/koji/taskinfo?taskID=142411636 - Fedora 43: https://koji.fedoraproject.org/koji/taskinfo?taskID=142411975 Reproducible: Always Steps to Reproduce: 1. Clone the latest vulkan-validation-layers from https://src.fedoraproject.org/rpms/vulkan-validation-layers/ 2. scratch-build it in my sidetag: fedpkg scratch-build --target=f45-build-side-129547 --arches aarch64 --srpm 3. The build will fail with the error mentioned Actual Results: The build fails. Only on aarch64. Expected Results: The build success like it does in other architectures.
These options were introduced to workaround a i686 issue a while ago: ``` %global optflags %(echo %{optflags} | sed 's/-g /-g1 /') %global optflags %(echo %{optflags} | sed 's/-O2 /-O1 /') ``` Removing them solves the issue. I'm not sure if this bug report is still something interesting to investigate and fix from the GCC point of view. If not, feel free to close this issue.