[Mesa-dev] Using the 'f' suffix to create a float from an integer literal

[Ian Romanick]

On 11/20/2014 05:33 AM, Neil Roberts wrote:
> For what it's worth, I did a quick grep through the internal and public
> shader-db and I couldn't find anything using this.
> 
>  git grep -P '\b(?<!e[+-])(?<![.0-9])[0-9]+f\b'
> 
> If AMD disallows it then it seems like it would be reasonably safe to
> disallow it in Mesa too.
> 
> GCC disallows it too which could be an indication that people won't have
> a habit of using it.

So... the GLSL spec actually follows C?  Then we should definitely
follow the spec, and there's no need for a GLSL spec bug.  If AMD
disallows it, then there are not likely to be any applications that
depend on it... so I agree with Neil that we're safe to disallow it too.

I'm still curious about glslang... if glslang allows it, I'll file a bug
against glslang. :)

> - Neil
> 
> Iago Toral <itoral at igalia.com> writes:
> 
>> On Thu, 2014-11-20 at 08:08 +0100, Iago Toral wrote:
>>> On Wed, 2014-11-19 at 10:27 -0800, Ian Romanick wrote:
>>>> On 11/19/2014 03:47 AM, Iago Toral Quiroga wrote:
>>>>> Hi,
>>>>>
>>>>> I came across a GLSL test that checks that doing something like this in
>>>>> a shader should fail:
>>>>
>>>> Is this one of the dEQP tests?
>>>
>>> Yes.
>>>
>>>>> float value = 1f;
>>>>
>>>> It seems like we have a test related to this in piglit somewhere... it
>>>> looks like tests/shaders/glsl-floating-constant-120.shader_test uses
>>>> that syntax, but it's not explicitly testing that feature.
>>>>
>>>>> However, this works fine in Mesa. Checking the spec I  see:
>>>>>
>>>>> Floating-point constants are defined as follows.
>>>>>      floating-constant:
>>>>>            fractional-constant exponent-part(opt) floating-suffix(opt)
>>>>>            digit-sequence exponent-part floating-suffix(opt)
>>>>>      fractional-constant:
>>>>>            digit-sequence . digit-sequence
>>>>>            digit-sequence .
>>>>>            . digit-sequence
>>>>>      exponent-part:
>>>>>            e sign(opt) digit-sequence
>>>>>            E sign(opt) digit-sequence
>>>>>      sign: one of
>>>>>            + -
>>>>>      digit-sequence:
>>>>>            digit
>>>>>            digit-sequence digit
>>>>>      floating-suffix: one of
>>>>>            f F
>>>>>
>>>>> which suggests that the test is correct and Mesa has a bug. According to
>>>>> the above rules, however, something like this is fine:
>>>>>
>>>>> float f = 1e2f;
>>>>>
>>>>> which I find kind of weird if the other case is not valid, so I wonder
>>>>> if there is a bug in the spec or this is on purpose for some reason that
>>>>> I am missing.
>>>>>
>>>>> Then, to make matters worse, I read this in opengl.org wiki [1]:
>>>>>
>>>>> "A numeric literal that uses a decimal is by default of type float​. To
>>>>> create a float literal from an integer value, use the suffix f​ or F​ as
>>>>> in C/C++."
>>>>>
>>>>> which contradicts the spec and the test and is aligned with the current
>>>>> way Mesa works.
>>>>>
>>>>> So: does anyone know what version is right? Could this be a bug in the
>>>>> spec? and if it is not, do we want to change the behavior to follow the
>>>>> spec as it is now?
>>>>
>>>> The $64,000 question: What do other GLSL compilers (including, perhaps,
>>>> glslang) do?  This seems like one of the cases where nobody is likely to
>>>> follow the spec, and some application will depend on that.  If that's
>>>> the case, I'll submit a spec bug.
>>>
>>> Good point. I'll try to check a few cases and reply here. Thanks!
>>
>> I did a quick test on AMD Radeon and nVidia proprietary drivers since I
>> had these easily available. AMD fails to compile (so it follows the
>> spec) but nVidia works (so same case as Mesa).
>>
>> This confirms your guess: different drivers are doing different things.
>> Is this enough to file a spec bug? I imagine that the result on glslang
>> won't change anything, but I can try to install it and test there too if
>> you think that's interesting anyway.
>>
>> Iago
>>
>> _______________________________________________
>> mesa-dev mailing list
>> mesa-dev at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/mesa-dev