[Mesa-dev] [PATCH 2/5] glsl: Ban #undefining __LINE__ and friends on GLES2.

Eric Anholt eric at anholt.net
Tue May 2 23:23:14 UTC 2017


Erik Faye-Lund <kusmabite at gmail.com> writes:

> On Tue, May 2, 2017 at 7:36 PM, Eric Anholt <eric at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20170502/dfada087/attachment-0001.sig>


More information about the mesa-dev mailing list