t_vb_arbprogram.c seems to miscompile when using any optimization flags (even -O1) with recent gcc (tried 4.1.0 and 4.1.1, it does not happen with 3.4.6). There are no compiler warnings, but rendering artifacts may happen. It is very easily visible with the doom3 main title screen, when the planet zooms in there are lots of bogus black parts on the planet - once it's zoomed in it suddenly looks correct (similar glitches happen in the game the whole time).
Tested with r200 (tcl_mode 0) as well as standalone mesa (using +set r_renderer r200 for doom3).
Not sure what's going on, it could also be a compiler bug.
forgot to mention, but the exact same thing happens when the codegen is used (with MESA_EXPERIMENTAL set to true, the glitches just render a lot faster...). It does not matter if t_vb_arbprogram_sse.c is compiled with optimization or not, it only depends on the optimization flags used for t_vb_arbprogram.c, even if codegen is used.
Ok fixed. Turns out it's nowhere near as dramatic as it looked. It did NOT miscompile, apparently the -ffast-math option (actually it was -funsafe-math-optimizations) caused slightly different results to fixed function vertex transform because a different function (though mathematically equivalent) was used for the transformation (not with -O0 though, maybe the optimizer can't really do much in that case). Results have to be the same however according to ARB_vp spec if the position invariant option is used. No wonder I saw errors only in doom3 - there is a reason the spec mentions that John Carmack requested this option with invariance to fixed function :-).
Mass version move, cvs -> git