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

[Iago Toral]

On Thu, 2014-11-20 at 09:33 -0800, Ian Romanick wrote:
> 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. :)

glslang follows the spec, it spits an error and fails to compile a
shader that uses that syntax.

Iago

> > - 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
> 
>