It also causes GPU hang.

dmesg:
[  179.747534] [drm:i915_gem_open]
[  179.805336] [drm:i915_gem_context_create_ioctl] HW context 1 created
[  179.909310] [drm:valleyview_set_rps] GPU freq request from 160 MHz (16) to 480 MHz (48)
[  185.752305] [drm] stuck on render ring
[  185.767345] [drm] GPU HANG: ecode 0:0x84dffffc, in glcts [3993], reason: Ring hung, action: reset
[  185.767363] [drm] GPU hangs can indicate a bug anywhere in the entire gfx stack, including userspace.
[  185.767369] [drm] Please file a _new_ bug report on bugs.freedesktop.org against DRI -> DRM/Intel
[  185.767374] [drm] drm/i915 developers can then reassign to the right component if it's not a kernel issue.
[  185.767382] [drm] The gpu crash dump is required to analyze gpu hangs, so please always attach it.
[  185.767387] [drm] GPU crash dump saved to /sys/class/drm/card0/error
[  185.767497] [drm:i915_error_work_func] resetting chip
[  185.769291] [drm:init_status_page] render ring hws offset: 0x00013000
[  185.769322] [drm:init_status_page] bsd ring hws offset: 0x00037000
[  185.769342] [drm:init_status_page] blitter ring hws offset: 0x0005a000
[  185.769361] [drm:init_status_page] video enhancement ring hws offset: 0x0007d000
[  185.769416] [drm:i9xx_update_primary_plane] Writing base 00889000 00000000 0 0 7680
[  187.633614] [drm:valleyview_set_rps] GPU freq request from 480 MHz (48) to 320 MHz (32)
[  187.637454] [drm:i915_gem_context_destroy_ioctl] HW context 1 destroyed
[  187.752369] [drm:cherryview_enable_rps] GT fifo had a previous error 1080000
[  187.752444] [drm:cherryview_enable_rps] PCBR offset : 0x7eef8001
[  187.754347] [drm:cherryview_enable_rps] GPLL enabled? yes
[  187.754354] [drm:cherryview_enable_rps] GPU status: 0x00202010
[  187.754359] [drm:cherryview_enable_rps] current GPU freq: 320 MHz (32)
[  187.754363] [drm:cherryview_enable_rps] setting GPU freq to 320 MHz (32)
[  187.754369] [drm:valleyview_set_rps] GPU freq request from 320 MHz (32) to 320 MHz (32)
[  187.856359] [drm:valleyview_set_rps] GPU freq request from 320 MHz (32) to 160 MHz (16)

Increasing priority, it has GPU hang issue.

Ben - are you actively looking at this issue?

I spent over a week trying to debug it. It works in simulation, and as far as we can tell there is no software bug. I've filed an HSD yesterday. No response yet.

Sorry, I need to correct that. I've filed an HSD on a different issue which we think is related. I will try to look at this one specifically.

Okay. I'm not convinced this is the same bug. I am investigating. There appears to be nothing wrong from the hardware perspective... need to investigate the generated shaders.

Full cmd

./glcts --deqp-surface-width=64 --deqp-surface-height=64 --deqp-base-seed=1 --deqp-surface-type=window --deqp-gl-config-id=14 --deqp-case=ES3-CTS.shaders.loops.do_while_dynamic_iterations.vector_counter_vertex

It looks like a more general problem with control flow instructions on CHV.

Can you confirm ./bin/shader_runner tests/shaders/glsl-vs-loop-300.shader_test fails for you as well?

Disregard test request. I am not able to reproduce the shader runner hang after reboot.

Please test my mesa branch: 
http://cgit.freedesktop.org/~bwidawsk/mesa/log/?h=b84212

(Should be SHA 7684eaf239cab0f54ee35b385b6c9205f513a082)

This fixes the issue for me.

Hua is on leave.
Shuo, could you follow up with Ben?

Apparently my push didn't actually work, and my machine at work has locked up. 

Looking at the docs closer, I don't believe what I did is correct anyway. I think the docs are telling me that you cannot program 3 as opposed to, you must program 3. We do not have a check for this, but we're not programming 3 in the failing case. Let's at least make sure this makes the test pass on your system (it does on mine). Then I'll come up with some more experiments.

Here is the patch from memory:
diff --git a/src/mesa/drivers/dri/i965/brw_eu_emit.c b/src/mesa/drivers/dri/i965/brw_eu_emit.c
index c475393..d3b1b32 100644
--- a/src/mesa/drivers/dri/i965/brw_eu_emit.c
+++ b/src/mesa/drivers/dri/i965/brw_eu_emit.c
@@ -517,6 +517,7 @@ brw_set_src1(struct brw_compile *p, brw_inst *inst, struct brw_reg reg)
         else
             brw_inst_set_src1_vstride(brw, inst, reg.vstride);
       }
+      brw_inst_set_src1_reg_type(brw, inst, 0x3);
    }
 }

Created attachment 109786 [details] [review]
Disable DDChk

Please test this instead of the diff I posted yestersday

Thanks Ben, verified and the case is pass.

I tested it by mesa10.4rc1 with kernel 3.18.0-rc5_drm-intel-nightly_3cb89f_20141119. The bug is reproduced.
Then I add Ben's patch into mesa10.4RC1, then the case is pass
After the patch is merged into master, I will close the bug.

The patches that I'd like to upstream are now on the mailing list:
http://patchwork.freedesktop.org/patch/37276/
http://patchwork.freedesktop.org/patch/37277/

Please verify they still fix the issue.

Nevermind. I pushed it to master.

Verified.Fixed.
[root@x-bsw01 cts]# ./glcts --deqp-case=ES3-CTS.shaders.loops.do_while_dynamic_iterations.vector_counter_vertex
dEQP Core GL-CTS-2.0 (0x0052484b) starting..
  target implementation = 'X11'

Test case 'ES3-CTS.shaders.loops.do_while_dynamic_iterations.vector_counter_vertex'..
Vertex compile time = 1.886000 ms
Fragment compile time = 0.710000 ms
Link time = 2.645000 ms
  Pass (Pass)

DONE!

Test run totals:
  Passed:        1/1 (100.00%)
  Failed:        0/1 (0.00%)
  Not supported: 0/1 (0.00%)
  Warnings:      0/1 (0.00%)