summaryrefslogtreecommitdiffstats
path: root/src/glx
diff options
context:
space:
mode:
authorNeil Roberts <neil@linux.intel.com>2014-08-14 15:01:39 +0100
committerNeil Roberts <neil@linux.intel.com>2014-08-15 12:35:40 +0100
commitaa9d4f9d1a01fbb829571dac1cf896a8288c7286 (patch)
treed10c8d628a473b9e2d1bcb0fcf5d09090cf46e69 /src/glx
parentafa7df9b78c0e7b14d2069faa8bc83aa2548b8e5 (diff)
downloadexternal_mesa3d-aa9d4f9d1a01fbb829571dac1cf896a8288c7286.zip
external_mesa3d-aa9d4f9d1a01fbb829571dac1cf896a8288c7286.tar.gz
external_mesa3d-aa9d4f9d1a01fbb829571dac1cf896a8288c7286.tar.bz2
i965/blorp_clear: Use memcpy instead of assignment to copy clear value
Similar to the problem described in 2c50212b14da27de4e3, if we copy the clear value through a regular assignment via a floating point value, then if an integer clear value is being used that happens to contain a signalling NaN value then it would get converted to a quiet NaN when stored via the x87 floating-point registers. This would corrupt the integer value. Instead we should use a memcpy to ensure the exact bit representation is preserved. This bug can be triggered on 32-bit builds with optimisations by using an integer clear color with a value like 0x7f817f81. Reviewed-by: Matt Turner <mattst88@gmail.com>
Diffstat (limited to 'src/glx')
0 files changed, 0 insertions, 0 deletions