[chbot] Compiler optimisation

Helmut Walle helmut.walle at gmail.com
Fri Jul 2 04:54:39 BST 2021


Regarding that question: if an element of a structure is qualified as 
volatile, only that element of any instances should become volatile, not 
the entire instance of the structure. Where you need the entire instance 
of the structure to be qualified as volatile, this can easily be 
achieved by qualifying the instantiation as volatile. Qualifying an 
entire instance of a structure makes all elements of that instance 
volatile. This is the respective example from the ISO C99 standard:

"

EXAMPLE 2 In:
     struct s { int i; const int ci; };
     struct s s;
     const struct s cs;
     volatile struct s vs;
the various members have the types:
     s.i int
     s.ci const int
     cs.i const int
     cs.ci const int
     vs.i volatile int
     vs.ci volatile const int

"

Optimisations tend to be highly implementation-dependent. However, the 
ISO C99 standard very clearly says the following about the volatile 
qualifier in subsection 6.7.3 (6), and in footnote 116, respectively:

"6 An object that has volatile-qualified type may be modified in ways 
unknown to the
implementation or have other unknown side effects. Therefore any 
expression referring
to such an object shall be evaluated strictly according to the rules of 
the abstract machine,
as described in 5.1.2.3. Furthermore, at every sequence point the value 
last stored in the
object shall agree with that prescribed by the abstract machine, except 
as modified by the
unknown factors mentioned previously.116) What constitutes an access to 
an object that
has volatile-qualified type is implementation-defined."

"116) A volatile declaration may be used to describe an object 
corresponding to a memory-mapped
input/output port or an object accessed by an asynchronously 
interrupting function. Actions on
objects so declared shall not be ‘‘optimized out’’ by an implementation 
or reordered except as
permitted by the rules for evaluating expressions."

So there is a little bit of wiggle room in that last sentence of 6.7.3 
(6), "What constitutes an access to an object [...]"

The remaining uncertainty then is is in the questions:

- whether the compiler was developed aiming at ISO C99 conformity in the 
first place, and

- even if it was intended to be ISO C99, whether it actually does meet 
all of the requirements of the standard.

Is it possible in your case to compile twice with the same optimisation, 
while making the smallest possible change to the volatile qualifiers 
(e.g., add or remove just one of them), and then comapring the assembly 
results? That would be one way of checking potential compiler issues for 
the respective optimisation level, and if not too onerous, this might 
help more to understand what is going on than looking at overall system 
behaviour.

The other general comment is that, while compiler bugs are not unheard 
of, they tend to be much rarer than errors in new code under 
development... So carefully reviewing your code for other common errors 
or risky constructs might be a good idea. I don't know whether this 
concern applies in your case, but if you get strange behaviour, how 
certain are you that the volatile questions are really causing it?

Kind regards,

Helmut.

On 2/07/2021 12:37, Robin Gilks wrote:
> I've managed to get the change in behaviour down to a single file now 
> and have started to sprinkle 'volatiles' about the place.
>
> Question - if an element of a structure is defined as volatile, does 
> the instantiation of the structure need to be also or does the whole 
> struct effectively become volatile.
>
> Cheers
>
> [...]



More information about the Chchrobotics mailing list