const volatile

David Brown david@westcontrol.com
Thu Sep 27 05:25:00 GMT 2018 

Again - /please/ keep gcc-help@gcc.gnu.org in the "to" or "cc" list so 
that these mails go to mailing list.  This is a public discussion and 
help, not personal email.


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:
> 
>     (Please keep the gcc help list on the copies here - it saves
>     duplication
>     of answers, and means everyone gets to see them.)
> 
>     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.*

Yes, that is true.

> The second part is the important part - since it implies the compiler 
> will not optimize those references away - in the case in hand this means 
> zero is not optimized away resulting in the wrong/no exception being 
> generated.
> 

And that is not true.

The compiler needs to generate the same /defined/ effects for division 
by zero whether the zero is given as a literal constant in the code, or 
read in some way (such as from a volatile variable).  If an operation 
has /undefined/ effect - such as integer division by 0 - then there is 
no correct behaviour to expect regardless of where the 0 comes from. 
For floating point division, it depends on the compiler and some 
settings (I am not an expert here).  If the effects are defined, then 
they will be the same for a compile-time constant and a 0 loaded from a 
volatile - if not, there is a bug in the compiler.

> This is only one of the many places it is used in the math code for this 
> specific reason.
> 

I am confident that this is either unnecessary, or a work-around for 
compiler problems.  Others with more expertise on floating point errors 
can confirm or correct this.

> 
>      >
>      >     It is rare to define "const volatile" variables.  It is
>     usually more
>      >     useful to declare pointers to them.  They are used for things
>     like
>      >     read-only hardware registers in microcontrollers, or for data
>     that is
>      >     set from outside a program but is constant from within it
>     (perhaps you
>      >     patch your binaries with a serial number, or a checksum - you
>     could use
>      >     a pointer to const volatile for reading the number in the code).
>      >
>      >     The only real use of defined "const volatile" variables I
>     have had is
>      >     for debugging - these would be variables that cannot be
>     changed by the
>      >     code, but you might change them via a debugger.  Usually such
>     things are
>      >     temporary during software development, and it's easier just
>     to make them
>      >     normal volatile variables.
>      >
>      >      > I am trying to compile code for m68k AmigaOS which is resident
>      >     using the
>      >      > mathlib functions which need certain constants as volatile
>     to prevent
>      >      > incorrect sequence re-ordering in gcc's optimizations -
>     however
>      >     doing so
>      >      > puts the value in bss data without const.
>      >      >
>      >
>      >     That is almost certainly not the best way to get the
>     sequencing you
>      >     want.  Post more details on what you are trying to do, and I
>     am sure
>      >     someone can give you advice.
>      >
>      >
>      > This comes from the standard sun mathlib code.
>      >
>      > Here’s one example where it isn’t for the sequence but to cause a
>      > controlled crash in the correct way -:
>      >
>     https://github.com/ezrec/AROS-mirror/blob/ABI_V1/AROS/compiler/stdc/math/e_log.c
>      >
> 
>     I am not an expert in floating point details, especially not for
>     non-finite things, but to my mind this code is clearly unnecessary. 
>     The
>     compiler will give the same result for "-two54 / vzero" whether
>     vzero is
>     declared "static const volatile double = 0.0;", or without the
>     volatile,
>     or given just as the literal 0.0 in the code.  Without the volatile,
>     the
>     code will be (marginally) shorter and faster as the construction of the
>     infinity will be done at compile-time instead of run-time.
> 
>     Wait for others to give an opinion before changing this, however.
> 
>      >
>      >      > How can we have a global that is both volatile (to prevent
>     incorrect
>      >      > sequencing) and const (so it is read only and stored in
>     read only
>      >     data
>      >      > section) ?
>      >
>      >     Why does it matter where the data is stored?
>      >
>      >
>      > Because .data/.bss cannot exist in the rom image.
> 
>     That is irrelevant.
> 
> 
> It is not irrelevant.
> 
> if the value is const - it is put in .rodata but the code may be (and 
> does end up) optimized incorrectly.

"Incorrect optimisation" sounds like a compiler bug.  I think it is more 
likely that the situation is a bug in the code, or the programmer's 
expectations.

> if the value is volatile - it is put in the .bss section and the code is 
> always compiled correctly. however we can not use it in rom because 
> .bss/.data sections cannot be used there.

That is, as I say, irrelevant.

The compiler (or, more accurately, the implementation - including linker 
and C startup library) will ensure that the variable has the correct 
initialised value before main() (or any global constructors, for C++) is 
called.  It does not matter if the object containing the "0.0" value is 
in rom or in ram, as long as it has the correct value.

> 
>        If the "const volatile" variable has an explicit
>     initialisation, it will be allocated to .data and initialised at
>     startup
>     just like any other initialised data variable.  If it is not explicitly
>     initialised, it will be allocated to .bss and zeroed at startup - like
>     any other uninitialised variable.
> 
>     It is only from /your/ code - code run after "main()" starts - that
>     "const" says you can't write to the variable.  The C startup code will
>     initialise it as normal before main() starts.
> 
> 
> I understand what you are saying fine - and I'm sorry if it seems I am 
> being argumentative - but it still sounds like the compiler is doing the 
> wrong thing when it knows from "const" that the data is to be read only. 

The compiler is not doing the wrong thing.  "const" does /not/ mean that 
the data is read only - it means that /you/ are not allowed to change 
it.  If the compiler also knows that it has full control of the variable 
- as is normally the case - then it knows a "const" variable can be put 
in rom data to save a little memory and perhaps improve cache locality. 
If the compiler knows that it does /not/ have full control - as is the 
case for a "volatile" - it will put it in modifiable ram.  That is where 
you would normally want your volatile variables, whether they are marked 
"const" or not.

> 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 actually checked to see if something is failing to work 
correctly?  As far as I can see, that could only happen if your system 
is otherwise broken and failing to correctly initialise the data 
section.  Have you checked that what you /think/ should happen is 
actually correctly defined behaviour, rather than just something that 
happens to be the case on some targets or some circumstances?

Have you looked at other solutions, such putting the zero in read-only 
memory as a normal "const" variable, and then using a forced volatile 
read of it?  ACCESS_ONCE from Linux helps for that:

	#define ACCESS_ONCE(v) *((volatile typeof((v)) *) &(v))

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.

More information about the Gcc-help mailing list