Re: const volatile

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 26 Sep 2018 at 21:06, David Brown <david@xxxxxxxxxxxxxxx> wrote:
> On 26/09/18 18:11, Kalamatee wrote:
> > On Wed, 26 Sep 2018 at 16:44, David Brown <david@xxxxxxxxxxxxxxx
> > <mailto:david@xxxxxxxxxxxxxxx>> wrote:
> >     On 26/09/2018 17:24, Kalamatee wrote:
> >      > On Wed, 26 Sep 2018 at 16:00, David Brown <david@xxxxxxxxxxxxxxx
> >     <mailto:david@xxxxxxxxxxxxxxx>
> >      > <mailto:david@xxxxxxxxxxxxxxx <mailto:david@xxxxxxxxxxxxxxx>>> 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




[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux