I can replicate this with a 32-bit build of Mesa on Sandybridge. However it also needs to be built with -O3. If I build with -O0 then the test passes. The fragment shader generated in both builds is identical.

Created attachment 104307[details]
Simpler test case
This bug is pretty strange. It seems to be related to uploading unsigned int uniforms. One of the tests tries to upload the value 2139193217 (which is 0x7f817f81). For some inexplicable reason this appears to end up in the shader as 0x7fc17f81, but only if you build with -O3.
I'm attaching a simpler test case which demonstrates it. It has a fragment shader with an unsigned int uniform and renders the four bytes of the uniform to a floating-point texture. It then prints out the values. You can specify an alternative test value as a command line argument.
It seems to be something very specific about having 0x7f in the most-significant 8 bits. 0x80, 0x6f or 0x8f work fine.
I am replicating this on a 32-bit build on SandyBridge. It doesn't happen on a 64-bit build with Haswell, but I'm not sure whether it's the SandyBridge or the 32-bit that's important.

Glenn Kennard on IRC pointed out that setting bit 22 like that resembles a NaN value getting munged when loading and storing through a floating-point register. Indeed if I write a quick test that does fld and fst with 0x7f817f81 it comes out as 0x7fc17f81. I guess this works on 64-bit because that will use SSE which apparently doesn't try to fix up NaNs on store. It also gets fixed on the 32-bit SandyBridge build if I use -mfpmath=sse and -msse2.