Androïd/x86 port of Mesa drivers https://git.hiegel.fr/cgit/android-x86-mesa.git/atom?h=r300 2010-08-23T17:48:10Z 2010-08-23T17:48:10Z Carl Worth cworth@cworth.org 2010-08-23T17:41:30Z urn:sha1:21560c40e8aa98624a225752b98babc7ae2938d5 We recently added several tests that intentionally trigger preprocessor errors. During valgrind-based testing, our test script was noticing the non-zero return value from the preprocessor and incorrectly flagging the valgrind-based test as failing. To fix this, we make valgrind return an error code that is otherwise unused by the preprocessor. 2010-08-11T21:38:03Z Carl Worth cworth@cworth.org 2010-08-11T20:06:36Z urn:sha1:2bcff4c879acec31ef0b39ecf04e9df41c5cbfab This allows writing tests that verify diagnostics from the preprocessor. 2010-08-11T19:46:16Z Carl Worth cworth@cworth.org 2010-08-11T19:46:16Z urn:sha1:8485f4d9aa6d98304bb0197dc4f1f357d81d1daa The glcpp-test script was leaving around bogus *.valgrind-errors files if a valgrind test was interrupted. 2010-08-11T01:27:31Z Carl Worth cworth@cworth.org 2010-08-11T01:27:31Z urn:sha1:9b7fd2099f926b9cc187382ca75eb8dedf3d37ca We're already using the return-value of cmp to print either PASS or FAIL and in the case of failure, we're subsequently running and showing the output of diff. So any warnings/errors from cmp itself are not actually needed, and can be quite confusing. 2010-07-21T00:01:11Z Carl Worth cworth@cworth.org 2010-07-20T00:49:23Z urn:sha1:d1500f8a195b7afe871cd768a5d33ecfecad5f31 As it turns out, 4 of our current tests are not valgrind clean, (use after free errors or so), so this will be helpful for investigating and fixing those. 2010-07-21T00:01:11Z Carl Worth cworth@cworth.org 2010-07-20T00:48:17Z urn:sha1:3a530b8ef68a40526b33de2af8de85f71ebdb30d And report PASS or FAIL for each test along the way as well. 2010-06-24T22:36:00Z Eric Anholt eric@anholt.net 2010-06-24T22:32:15Z urn:sha1:29285882676388aacff123e8bdf025904abf8ea9