Androïd/x86 port of Mesa drivers https://git.hiegel.fr/cgit/android-x86-mesa.git/atom?h=r300 2011-03-03T18:42:37Z 2011-03-03T18:42:37Z Kenneth Graunke kenneth@whitecape.org 2011-03-03T07:26:24Z urn:sha1:b56f30c2b23f6d7b5499f01fa2d3ee04f2ce546e The expected result has been out of sync with what glcpp produces for some time; glcpp's actual result seems to be correct and is very close to GCC's cpp. Updating this will make it easier to catch regressions in upcoming commits. 2011-01-28T22:21:05Z Carl Worth cworth@cworth.org 2011-01-28T22:19:39Z urn:sha1:2a18d1950c84c96d263cc8f15434502e03aeb1dc This reverts commit d3df641f0aba99b0b65ecd4d9b06798bca090a29. The original commit had sat unpushed on my machine for months. By the time I found it again, I had forgotten that we had decided not to use this change after all, (the relevant test was removed long ago). 2011-01-28T05:16:36Z Carl Worth cworth@cworth.org 2010-08-23T18:38:45Z urn:sha1:d3df641f0aba99b0b65ecd4d9b06798bca090a29 The GLSL specification is vague here, (just says "as is standard for C++"), though the C specifications seem quite clear that this should be an error. However, an existing piglit test (CorrectPreprocess11.frag) expects this to be a warning, not an error, so we change this, and document in README the deviation from the specification. 2011-01-05T00:39:19Z Vinson Lee vlee@vmware.com 2011-01-05T00:39:19Z urn:sha1:5a3f31575bf0657661c3e66a4c95c3298c78e441 2011-01-04T21:18:19Z Vinson Lee vlee@vmware.com 2011-01-04T21:18:19Z urn:sha1:6530944b502a0f35b305ee35c1c6f1e32a887721 2010-12-28T07:20:35Z Vinson Lee vlee@vmware.com 2010-12-28T07:20:35Z urn:sha1:f3319561a476bd806005551251dbc6a37f266e03 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-23T17:48:10Z Carl Worth cworth@cworth.org 2010-08-23T16:26:44Z urn:sha1:2a9e791fdeb45080a98042d41c153ea19c17caae This test exposes two current bugs: 1. The source number is not being correctly emitted in error messages (instead, it's always 0). 2. A directive of "#line 0" is resulting in the following parse error: preprocessor error: Invalid tokens after # 2010-08-23T17:48:10Z Carl Worth cworth@cworth.org 2010-08-23T15:54:06Z urn:sha1:0acd68c4050fea82797f80ad90212926df4cf001 This directive is already implemented nicely, but wasn't previously tested. It will be convenient to use this directive in further tests that rely on error messages, (such as ensuring that #line correctly sets the line number in the error message). 2010-08-18T06:41:53Z Carl Worth cworth@cworth.org 2010-08-18T06:19:01Z urn:sha1:105e2137d67b98c24251be3586985fb61aeaf28a The specification says that redefining a macro is an error, unless the new definitions is identical to the old one, (identical replacement lists but ignoring differing amounts of whitespace).