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

[Neil Roberts]

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.

- 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