Nasty workaround for apparent GCC bug

This is a horrible workaround for what I think must be a GCC bug.  Remove that usleep(1),
or go back to the original CLAMP() macro, and glxdemo will have a white background
instead of a grey one.  That is to say, the value 0.5 is getting clamped to 1.0 because
of some underlying floating-point weirdness.  This happens when cross-compiling for
armv4t-angstrom-linux-gnueabi with GCC version 4.1.1 or 4.3.2.

1 files changed, 20 insertions, 4 deletions

diff --git a/src/mesa/main/clear.c b/src/mesa/main/clear.c
index 8085bedf1c..2494585128 100644
--- a/src/mesa/main/clear.c
+++ b/src/mesa/main/clear.c
@@ -37,6 +37,8 @@
 #include "enums.h"
 #include "state.h"
 
+#include <unistd.h>	/* Needed for usleep() */
+
 
 
 #if _HAVE_FULL_GL
@@ -60,6 +62,20 @@ _mesa_ClearIndex( GLfloat c )
 #endif
 
 
+/* Nasty workaround - the same as CLAMP(x, min, max), but fudged to avoid
+ * some kind of problematic copmiler optimisation */
+static GLfloat clamp_clear(GLclampf x, GLfloat min, GLfloat max)
+{
+	if ( x > max ) {
+		return max;
+	}
+	if ( x < min ) {
+		return min;
+	}
+	usleep(1);
+	return x;
+}
+
 /**
  * Specify the clear values for the color buffers.
  *
@@ -81,10 +97,10 @@ _mesa_ClearColor( GLclampf red, GLclampf green, GLclampf blue, GLclampf alpha )
    GET_CURRENT_CONTEXT(ctx);
    ASSERT_OUTSIDE_BEGIN_END(ctx);
 
-   tmp[0] = CLAMP(red,   0.0F, 1.0F);
-   tmp[1] = CLAMP(green, 0.0F, 1.0F);
-   tmp[2] = CLAMP(blue,  0.0F, 1.0F);
-   tmp[3] = CLAMP(alpha, 0.0F, 1.0F);
+   tmp[0] = clamp_clear(red,   0.0F, 1.0F);
+   tmp[1] = clamp_clear(green, 0.0F, 1.0F);
+   tmp[2] = clamp_clear(blue,  0.0F, 1.0F);
+   tmp[3] = clamp_clear(alpha, 0.0F, 1.0F);
 
    if (TEST_EQ_4V(tmp, ctx->Color.ClearColor))
       return; /* no change */