Hi, could you provide more information about your system and the issue?
Which mesa version are you using?

(In reply to Elizabeth from comment #1)
> Hi, could you provide more information about your system and the issue?
> Which mesa version are you using?

Mesa 17.3.6-1, Arch Linux

Any way to reproduce this? Is functional on previous mesa versions or alternative configuration?

Created attachment 138154 [details]
This program causes the hang

This program causes the hang. Uncommenting the commented section in "shadershadow.geometry.txt" stops the hang.

There are such results for the present moment:

There are NO any GPU HANGs (commented out or not the noted section in "shadershadow.geometry.txt").

Tests were ran with mesa 17.3.[6-8].
In mesa 17.3.6 and 17.3.7 an error occured: "Mesa: User error: GL_INVALID_ENUM in glEnable(GL_TEXTURE_2D)" (in main.cpp:707:8)

System:    Kernel: 4.15.14-1-MANJARO x86_64 bits: 64 Desktop: Cinnamon 3.6.6 
           Distro: Manjaro Linux 17.1.7 Hakoila 
CPU:       Topology: Quad Core model: Intel Core i5-3470 type: MCP L2 cache: 6144 KB 
           Speed: 3501 MHz min/max: 1600/3600 MHz Core speeds (MHz): 1: 3534 2: 3583 3: 3588 4: 3551 
Graphics:  Card-1: Intel Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller driver: i915 v: kernel

Waiting for a SANDYBRIDGE for next steps.

I have "Intel(R) Celeron(R) CPU G530 @ 2.40GHz", maybe it matters.

Created attachment 140223 [details]
shader_test to reproduce tihs issue

I have reproduced it on SNB.
I think that I found the root cause of the issue.
I have created the patch to fix it:
https://patchwork.freedesktop.org/patch/230255/

I have created shader_test to reproduce this issue also.

(In reply to asimiklit from comment #8)
New link of the patch: https://patchwork.freedesktop.org/patch/230342/

Created attachment 140260 [details]
Added dump of Geomery Shader (NIR, Assembler) which leads to GPU hang (mesa 1802 dev)

Created attachment 140261 [details]
Added dump of Geometry Shader (NIR, Assembler) where this issue is fixed by workaround v2 in compiller

Fixed in master with:

commit 232c5d75ea8c9536a896a17c9156b8e2ad36a779 (HEAD -> master)
Author: Andrii Simiklit <asimiklit.work@gmail.com>
Date:   Fri Jun 22 10:59:57 2018 +0300

    i965/gen6/gs: Handle case where a GS doesn't allocate VUE
    
    We can not use the VUE Dereference flags combination for EOT
    message under ILK and SNB because the threads are not initialized
    there with initial VUE handle unlike Pre-IL.
    So to avoid GPU hangs on SNB and ILK we need
    to avoid usage of the VUE Dereference flags combination.
    (Was tested only on SNB but according to the specification
    SNB Volume 2 Part 1: 1.6.5.3, 1.6.5.6
    the ILK must behave itself in the similar way)
    
    v2: Approach to fix this issue was changed.
    Instead of different EOT flags in the program end
    we will create VUE every time even if GS produces no output.
    
    v3: Clean up the patch.
    Signed-off-by: Andrii Simiklit <andrii.simiklit@globallogic.com>
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105399
    CC: <mesa-stable@lists.freedesktop.org>
    Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
    Tested-by: Mark Janes <mark.a.janes@intel.com>