I am developing for a project an STM32 Cortex processor, using gcc on
Eclipse. Initially I am working with the ST Electronics
STM32F10x-128K-EVAL demo board, which included an LCD display and a
joystick.
I need to reset the backup domain, so I want to pulse bit 16 of the RCC
backup domain control register. I have a macro definition to access
this bit using bit banding.
In my code I included two consecutive lines:
RCC_BDRST = 1;
RCC_BDRST = 0;
If I set the optimisation to -O0 or -O1 the code compiles and functions
correctly, but inefficiently. The machine code loads r3 with the
bit-banding register address (0x42420440), then loads r2 with 1, writes
r2 to address r3, then again loads r3 with 0x42420440, loads r2 with 0
then writes r2 to address r3.
Not only is this inefficient, at these level of optimisation for some
reason the processor is unable to write to the LCD display.
If I change the optimisation to -Os the processor is able to write to
the display, but no machine code is generated for the instructions
above.
If I change the optimisation to -O2 the processor is unable to write to
the display, and again no code is generated for the instructions above.
It seems to me that in the process of optimising the code, gcc sees that
the overall effect of the above two line of code is to have no change to
the initial state of the relevant flag, so it skips them. This is
obviously not right.
According to the gcc manual the various optimisation levels activate
different combinations of optimisation flags. Obvioulsy one of these
affects the code that interfaces to the LCD display, and another
inhibits implementation of the desired reset code.
I guess I could leave the optimisation at -O0 but include all the flags
that would be invoked by -Os, then delete one flag at a time until I
find which are responsible for the two problems. Does anyone have any
other suggestions?

Since the behaviour of the code you posted would be entirely dependent
on the definition of the macro, you should have posted the definition.
Just showing the un-preprocessed code tells us nothing.
I would have 'guessed' the same solution as Andreas given the symptoms,
but it was still a guess (albeit an educated one), you got lucky.
> This is obviously not right.
No, actually that was exactly right. Some useful reading for you:
http://www.embedded.com/story/OEG20010615S0107
Clifford