Erik Faye-Lund <kusmab...@gmail.com> writes: > On Tue, May 2, 2017 at 7:36 PM, Eric Anholt <e...@anholt.net> wrote: >> Fixes deqp_gles2 undefine_invalid_object_* failures. >> --- >> src/compiler/glsl/glcpp/glcpp-parse.y | 7 ++----- >> 1 file changed, 2 insertions(+), 5 deletions(-) >> >> diff --git a/src/compiler/glsl/glcpp/glcpp-parse.y >> b/src/compiler/glsl/glcpp/glcpp-parse.y >> index e113253061f6..5cb2a380605b 100644 >> --- a/src/compiler/glsl/glcpp/glcpp-parse.y >> +++ b/src/compiler/glsl/glcpp/glcpp-parse.y >> @@ -284,7 +284,8 @@ control_line_success: >> * It is an error to undefine or to redefine a built-in >> * (pre-defined) macro name. >> * >> - * The GLSL ES 1.00 spec does not contain this text. >> + * The GLSL ES 1.00 spec does not contain this text, but >> + * dEQP's preprocess test in GLES2 checks for it. > > Wouldn't it be better to fix dEQP? Or at least get Khronos to clarify the > spec? > > I mean, the spec is what defines the behavior, not dEQP. There's been > a bunch of mistakes in dEQP that has been corrected, why would this be > any different?
Khronos regularly redefines old specs to say new things, and sometimes they do so without updating the PDFs. The preprocessor is extremly underspecified, so this new GLES3 spec text is likely clarification of what old behavior should have been.
signature.asc
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/mesa-dev
