Affected tests:

dEQP-GLES3.functional.rasterization.primitives.line_strip_wide
dEQP-GLES3.functional.rasterization.primitives.line_loop_wide

In these cases it looks like one of the edges of a line is outside the viewport (right end of the viewport). The hardware seems to clip using the rightmost edge of the line as reference, but this means that the leftmost side is clipped before it should according to dEQP.

Enabling the guardand test in gen7 fixes this, but a comment in the code suggests that we should not do this to prevent rendering to the underlying surface outside the viewport region (gen8 hw fixes this apparently), so if the guardband is not disabled for this case in gen8 this may be fixed for gen8+.

The OpenGL spec is not clear as to how clipping should work with wide lines, but it suggests that for xmajor lines, columns of pixels should be rendered, and that is not what is happening here (but that section does not consider clipping to any extent). Some texts seem to suggest that OpenGL expects wide lines to be rendered as multiple width=1 lines. If this is the case, then deqp is right and intel rendering is bogus (intel renders a paralelogram), but nothing in the OpenGL spec seems to make this clear. I think clipping with wide lines is not clearly specified.

So this might be a bogus tests or incorrect. We had some discussion on this topic in the mailing list:
http://lists.freedesktop.org/archives/mesa-dev/2015-February/076072.html

Although I don't think there is a clear conclusion I believe that the spirit of the spec is the one represented by dEQP expectations.