On Wed, May 3, 2017 at 1:23 AM, Eric Anholt <[email protected]> wrote: > Erik Faye-Lund <[email protected]> writes: > >> On Tue, May 2, 2017 at 7:36 PM, Eric Anholt <[email protected]> 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.
Actually, seems there's already at least some form for spec-backing for this. The wording "#define and #undef functionality are defined as for C++, for macro definitions both with and without macro parameters." from section 3.4 Preprocessor of the OpenGL ES Shading Language 1.00 spec, combined with "If any of the pre-defined macro names in this subclause, or the identifier defined, is the subject of a #define or a #undef preprocessing directive, the behavior is undefined." from section 16.8.3 [cpp.predefined] of the ISO C++98 (which was the most recent C++ specification at the time the GLSL ES 1.00 was written) should also imply that an error is OK. _______________________________________________ mesa-dev mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/mesa-dev
