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

[Jose Fonseca]

> The $64,000 question: What do other GLSL compilers (including, perhaps,glslang) do?

:) Shouldn't this be the "$1e6f question"?

Jose
________________________________________
From: mesa-dev <mesa-dev-bounces at lists.freedesktop.org> on behalf of Iago Toral <itoral at igalia.com>
Sent: 20 November 2014 07:08
To: Ian Romanick
Cc: mesa-dev at lists.freedesktop.org
Subject: Re: [Mesa-dev] Using the 'f' suffix to create a float from an integer literal

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!

Iago

> > Thanks,
> > Iago
> >
> > [1] https://urldefense.proofpoint.com/v2/url?u=https-3A__www.opengl.org_wiki_Data-5FType-5F-28GLSL-29&d=AAIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzE&m=-vNxCjRApDMGfEN7OH0gdQY45tX4GCnJezazsrd2DNg&s=v-iOTBhqyw5b2dul6DNiwG3s4jGuIujxKjaxWWGRqc8&e=
> >
> > _______________________________________________
> > mesa-dev mailing list
> > mesa-dev at lists.freedesktop.org
> > https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddev&d=AAIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzE&m=-vNxCjRApDMGfEN7OH0gdQY45tX4GCnJezazsrd2DNg&s=YtsceeKLkQZUT8ymwqfviOL4cuiZKwMSPLqvO44zptE&e=
>
>


_______________________________________________
mesa-dev mailing list
mesa-dev at lists.freedesktop.org
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.freedesktop.org_mailman_listinfo_mesa-2Ddev&d=AAIGaQ&c=Sqcl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=zfmBZnnVGHeYde45pMKNnVyzeaZbdIqVLprmZCM2zzE&m=-vNxCjRApDMGfEN7OH0gdQY45tX4GCnJezazsrd2DNg&s=YtsceeKLkQZUT8ymwqfviOL4cuiZKwMSPLqvO44zptE&e=