The regression is introduced with the glsl2 branch merge.

(In reply to comment #1)
> The regression is introduced with the glsl2 branch merge.

Is this swrast the one built as a stand-alone libGL (e.g., make linux-x86) or swrast_dri.so?  This test has always failed on swrast_dri.so due to the alpha readback bug (alpha is always 0).

Though, looking more closely, swrast_dri.so gives this failure in addition to alpha=0.

FAILURE:
  Shader test: texture2D()
  Expected color: 1, 0, 0, 1
  Observed color: 0.498039, 0, 0, 0

MESA_GLSL=dump shows the instructions listed below.  These look correct, so I'm not sure what the error is.

Mesa IR for linked fragment program 2:
  0: (tex (var_ref tex2d@0x90547c0)  (swiz xy (array_ref (var_ref gl_TexCoord@0x9050178) (constant int (0)) ) ) (0 0 0) 1 () )
     MOV TEMP[1], INPUT[4].xyyy;
  1: TEX TEMP[2], TEMP[1], texture[0], 2D;
  2: (assign (constant bool (1)) (xyzw) (var_ref gl_FragColor@0x9054530)  (tex (var_ref tex2d@0x90547c0)  (swiz xy (array_ref (var_ref gl_TexCoord@0x9050178) (constant int (0)) ) ) (0 0 0) 1 () )) 
     MOV OUTPUT[1], TEMP[2];
  3: END

Perhaps there's some bad interaction with fixed-function?  The test passes with hardware drivers, so this is odd.

The problem seems to stem from the bogus way that swrast handles derivatives.  Since there's an extra MOV instruction, fetech_texel decides that there is no derivative available and fetches from the texture's base level.  This results in the wrong color.

I'm a little surprised that the copy propagation pass doesn't fix this.  I'll take a look into it, but I don't know that this will get fixed for 7.9.

I just ran this test, and it passes.  I also don't see the extra MOV instruction in the generated code.

mesa: 00792e3586746c833ffc9bb65712e38038916e06 (master)

Verified glean1 texture2D passes on swrast at the above commit.