[Mesa-dev] A few fixes for the preprocessor for GLSL 1.30

[Kenneth Graunke]

On 02/22/2013 01:14 PM, Carl Worth wrote:
> Ian Romanick <idr at freedesktop.org> writes:
>> Though, it turns out that this deviates from what C99 specifies.
>> Specifically, the ISO/IEC 9899:TC2 Committee Draft dated May 6, 2005 says:
>>
>>       "After all replacements due to macro expansion and the defined unary
>>       operator have been performed, all remaining identifiers are replaced
>>       with the pp-number 0..."
>>
>> I've submitted a GLSL spec bug.
>>
>> In the mean time, I'd suggest leaving the tests and our implementation
>> as-is.
>
> Hi Ian,
>
> Back in September, 2011, I did leave the test and implementation as-is.
>
> Then, in June 2012, I changed the behavior of our implementation, (I
> believe this was in response to an upcoming change in the specification
> you were aware of). At the time, I updated some "make check" tests, but
> failed to update piglit, (leading to bugzilla bug #51631).
>
> I'd like to fix that now. I can see by comparing the GLSL 4.30
> specification to GLSL 1.30 that the following sentence has been dropped,
> (justifying the currently implemented behavior in Mesa):
>
> 	It is an error to use #if or #elif on expressions containing
> 	undefined macro names, other than as arguments to the
> 	defined operator.
>
> But I'd like a little guidance on what to do with the piglit test. We're
> still only support GLSL 1.30 in our implementation, right? Should we be
> supporting the formerly-specified behavior until we start seeing
> "#version 430"?
>
> Or should we change piglit to just check for the new behavior, even with
> the old version? (You mentioned earlier in this thread that AMD and
> nVidia binary blobs were previously implementing the new behavior
> anyway).
>
> -Carl

I'd recommend assuming the new behavior in all language versions, with a 
comment in the test indicating that both AMD and nVidia's drivers have 
this behavior, so it's the de facto standard.

My $0.02 anyway.