On Tue, May 18, 2021 at 04:59:50PM -0600, Jeff Law wrote:
On 5/18/2021 4:44 PM, David Airlie wrote:
>
https://kojipkgs.fedoraproject.org//work/tasks/3814/68223814/build.log
>
> cd
/builddir/build/BUILD/Vulkan-ValidationLayers-sdk-1.2.176.1/i686-redhat-linux-gnu/layers
> && /usr/bin/g++ -DAPI_NAME=\"Vulkan\" -DVK_ENABLE_BETA_EXTENSIONS
> -DVK_USE_PLATFORM_WAYLAND_KHR -DVK_USE_PLATFORM_WAYLAND_KHX
> -DVK_USE_PLATFORM_XCB_KHR -DVK_USE_PLATFORM_XCB_KHX
> -DVK_USE_PLATFORM_XLIB_KHR -DVK_USE_PLATFORM_XLIB_KHX
> -DVK_USE_PLATFORM_XLIB_XRANDR_EXT -DVkLayer_khronos_validation_EXPORTS
> -I/builddir/build/BUILD/Vulkan-ValidationLayers-sdk-1.2.176.1/layers
> -I/builddir/build/BUILD/Vulkan-ValidationLayers-sdk-1.2.176.1/layers/generated
> -I/usr/include/glslang -I/usr/include/spirv/include
> -I/builddir/build/BUILD/Vulkan-ValidationLayers-sdk-1.2.176.1/i686-redhat-linux-gnu
>
-I/builddir/build/BUILD/Vulkan-ValidationLayers-sdk-1.2.176.1/i686-redhat-linux-gnu/layers
> -O2 -flto=auto -ffat-lto-objects -fexceptions -g1
> -grecord-gcc-switches -pipe -Wall -Werror=format-security
> -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
> -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1
> -m32 -march=i686 -mtune=generic -msse2 -mfpmath=sse -mstackrealign
> -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
> -Wpointer-arith -Wno-unused-function -Wno-sign-compare -DNDEBUG -fPIC
> -Wall -Wextra -Wno-unused-parameter -Wno-missing-field-initializers
> -fno-strict-aliasing -fno-builtin-memcmp -fvisibility=hidden
> -Wimplicit-fallthrough=0 -std=gnu++11 -MD -MT
> layers/CMakeFiles/VkLayer_khronos_validation.dir/generated/chassis.cpp.o
> -MF CMakeFiles/VkLayer_khronos_validation.dir/generated/chassis.cpp.o.d
> -o CMakeFiles/VkLayer_khronos_validation.dir/generated/chassis.cpp.o
> -c
/builddir/build/BUILD/Vulkan-ValidationLayers-sdk-1.2.176.1/layers/generated/chassis.cpp
> cc1plus: out of memory allocating 65536 bytes after a total of 3310292992 bytes
>
> We already use -g1 to try and reduce memory usage, and I tried not
> doing parallel jobs in case it was too much? any suggestions, is this
> LTO?
Not likely LTO since this isn't a link phase AFAICT.
And parallel jobs reduction isn't likely to help out, it looks like the
single cc1plus process is hitting the 3GB/1GB split anyhow. ;(
Not sure what to suggest here...
kevin