Created attachment 143285 [details]
vulkan-cube backtrace

It seems like we can't reproduce the problem. Where your mesa comes from?

(In reply to Samuel Pitoiset from comment #2)
> It seems like we can't reproduce the problem. Where your mesa comes from?

https://koji.fedoraproject.org/koji/buildinfo?buildID=1183327

Tested Rise of the Tomb Raider : I get a system hang (I am going to report a regression because I did clear the game on 04/2018).
No pb with dota2 vulkan, artifact (vulkan) or cs:go (opengl)
I use a gfx stack git from sunday: linux (amd-staging-drm-next), drm, llvm, mesa-gl, mesa-vulkan, xserver, xf86-video-amdgpu

Which gcc versiob do you use?(In reply to Sylvain BERTRAND from comment #4)
> Tested Rise of the Tomb Raider : I get a system hang (I am going to report a
> regression because I did clear the game on 04/2018).
> No pb with dota2 vulkan, artifact (vulkan) or cs:go (opengl)
> I use a gfx stack git from sunday: linux (amd-staging-drm-next), drm, llvm,
> mesa-gl, mesa-vulkan, xserver, xf86-video-amdgpu

Which gcc version do you use?

Fedora already moved to gcc 9.0.1

Could be an issue related to GCC 9.

(In reply to Samuel Pitoiset from comment #6)
> Could be an issue related to GCC 9.

Can you test MESA with GCC9 ?

Created attachment 143323 [details]
vulkan-cube backtrace + mesa 19.0.0 rc2

With mesa 19.0.0 rc2 I has same crashes.

https://koji.fedoraproject.org/koji/buildinfo?buildID=1206254

Hi,

After messing for a while with godbolt, it seems like GCC 9 considers literal scope to end with a block and not a function [1], or at least this is my assumption. In the godbolt example you can see the "1" assignments being dropped from the assembly when they are inside the switch scope.

When a literal assignment (like the following in radv_meta_blit.c build_pipeline function) happens inside a switch case, GCC 9 probably drops it:

--- SNIP ---

switch(aspect) {
case VK_IMAGE_ASPECT_COLOR_BIT:
	vk_pipeline_info.pColorBlendState = &(VkPipelineColorBlendStateCreateInfo) {
		.sType = VK_STRUCTURE_TYPE_PIPELINE_COLOR_BLEND_STATE_CREATE_INFO,
		.attachmentCount = 1,
		.pAttachments = (VkPipelineColorBlendAttachmentState []) {
			{ .colorWriteMask =
			VK_COLOR_COMPONENT_A_BIT |
			VK_COLOR_COMPONENT_R_BIT |
			VK_COLOR_COMPONENT_G_BIT |
			VK_COLOR_COMPONENT_B_BIT },
		}
	};
	break;

--- SNIP ---

You could work this around by giving names to the literals and putting them in the function scope (not inside any block). As I am not familiar with the C standard, I am not sure if what GCC 9 assumes is legal or not.


[1] https://godbolt.org/z/wTuMH-

https://www.gnu.org/software/gcc/gcc-9/porting_to.html

Block scope compound literal's lifetime

The C standard says that compound literals which occur inside of the body of a function have automatic storage duration associated with the enclosing block. Older GCC releases were putting such compound literals into the scope of the whole function, so their lifetime actually ended at the end of containing function. This has been fixed in GCC 9. Code that relied on this extended lifetime needs to be fixed, move the compound literals to whatever scope they need to accessible in.


      struct S { int a, b; };
      int foo(void) {
        // The following line no longer compiles
        struct S *p = &({ (struct S) { 1, 2 }; });
        struct S *q;
        {
          q = &(struct S) { 3, 4 };
        }
        // This is invalid use after lifetime of the compound literal
        // ended.
        return q->b;
      }

Should be fixed with https://patchwork.freedesktop.org/series/56485/

(In reply to Samuel Pitoiset from comment #12)
> Should be fixed with https://patchwork.freedesktop.org/series/56485/

Thanks. I tested this patch and can confirm that problem was fixed.

Fixed.

https://cgit.freedesktop.org/mesa/mesa/commit/?id=129a9f4937b8f2adb4d37999677d748d816d611c

-rc3 will have the fix.