const volatile

[Rob]

On Wed, 26 Sep 2018 at 21:06, David Brown <david@westcontrol.com> wrote:
> On 26/09/18 18:11, Kalamatee wrote:
> > On Wed, 26 Sep 2018 at 16:44, David Brown <david@westcontrol.com
> > <mailto:david@westcontrol.com>> wrote:
> >     On 26/09/2018 17:24, Kalamatee wrote:
> >      > On Wed, 26 Sep 2018 at 16:00, David Brown <david@westcontrol.com
> >     <mailto:david@westcontrol.com>
> >      > <mailto:david@westcontrol.com <mailto:david@westcontrol.com>>> wrote:
> >      >
> >      >     On 26/09/18 14:54, Kalamatee wrote:
> >      >      > Hi
> >      >      >
> >      >      > I am wondering if there is a reason globals marked const
> >     volatile
> >      >     are put
> >      >      > into the data section and not read-only as const should imply?
> >      >      >
> >      >
> >      >     "const" says /you/ promise not to change the value from your
> >     code.
> >      >     "volatile" says that something else might change its value
> >     unknown to
> >      >     the compiler.
> >
> >
> > That’s not ‘all’ it says. To be precise volatile tells the compiler that
> > the object is subject to sudden change for reasons which cannot be
> > predicted from a study of the program itself*, and forces every
> > reference to such an object to be a genuine reference.*
>
> > My only interest is in getting the issue resolved "correctly".
> >
> > For now I guess I will have to add the section attribute to all constant
> > volatiles to force the correct thing to happen.
>
> ...
>
> Have you looked at what happens if you use 0.0 instead of this "volatile
> const", to see that it is in some way necessary?
>
>
> As I say, I am not an expert on floating point errors.  But my feeling
> here is that you will get exactly the same results in all cases - which
> may not be the results you think you should get.
>

If it helps, this is likely related to a bugfix that went into freebsd's libm a
while back after they switched to clang. I can't remember the details, but I
believe the bug was to do with clang incorrectly constant-folding floating
point expressions in the wrong rounding mode, or perhaps how it interacted with
fesetround() and the fenv access pragmas.

The mirror here [1] shows the fix.

-
Rob

1: https://github.com/freebsd/freebsd/commit/e7b0a63c190c7ecb475b09f41387a75952540f49