volatile cast: GCC Bug oder gültige Optimierung

[Thomas (Gast)]

Ich habe hier ein kleines Problem, für welches ich zwar einen Workaround 
habe, aber nicht sicher bin, ob das ein GCC Bug ist.

Und zwar sollen im Code Zeichen asynchron über den UART gelesen werden 
bis ein gültiges Längenbyte (!=0) kommt. Über den Code Stil kann man 
streiten, aber er sollte so funktionieren, und tat das auch bis wir Link 
Time Optimization verwendeten und dabei ein Call durch Inlinen ersetzt 
wurde.

Ich hab als Beispiel was gebastelt, das diese Auffälligkeiten zeigt, 
dabei sind 3 Beispiele zu sehen, im ersten wird bei der if Überprüfung 
in der Schleife der zweite Teil weggelassen, obwohl auf (volatile ...) 
gecastet. Darf der Compiler das, obwohl ich ihm sage die Variable kann 
sich (durch die UART ISR) ändern?
Bei den beiden anderen Varianten wird alles wie gewünscht ausgeführt. Am 
besten man kompiliert das immer nur mit einer Schleife, dann sieht man 
im Listing was ich meine. Optimierung ist -Os mit GCC 4.7.2 von 
Launchpad

Plattform ist ein STM32

#include <stdint.h>
 
static char m_cRecBuffer[23];

void __attribute__((noinline)) uart_read_async(uint8_t* pa_pcBuffer, int pa_nLen)
{
   volatile uint8_t * pUartBusy = (volatile uint8_t*)0x42; 
   *pUartBusy = 1;
}
 
 uint8_t __attribute__((noinline)) uart_is_busy()
 {
    volatile uint8_t * pUartBusy = (volatile uint8_t*)0x42; 
   return *pUartBusy; 
 }
 
 void _exit(int pa_Exit)
 {
 }
 
int main(void)
{

   m_cRecBuffer[0] = 0;
   uart_read_async(&m_cRecBuffer[0], 1);
   
   // some pointer to uart driver status, changed in uart ISR
   volatile uint8_t * p_UartBusy = (volatile uint8_t*)0x42; 
   
   // not working
   /*
   * second condition in if is ignored (0 == (volatile uint8_t)m_cRecBuffer[0])
   */
   while ((0 == (volatile uint8_t)m_cRecBuffer[0])) {
    if (*p_UartBusy != 0 && (0 == (volatile uint8_t)m_cRecBuffer[0])) {
      uart_read_async(&m_cRecBuffer[0], 1);
    }
   }
   
   // working
   while ((0 == (volatile uint8_t)m_cRecBuffer[0])) {
    if (uart_is_busy() != 0 && (0 == (volatile uint8_t)m_cRecBuffer[0])) {
      uart_read_async(&m_cRecBuffer[0], 1);
    }
   }
   
   // working
   volatile uint8_t * pcLen = (volatile uint8_t*) &m_cRecBuffer[0];
   while (0 == *pcLen) {
    if (*p_UartBusy != 0 && 0 == *pcLen) {
      uart_read_async(&m_cRecBuffer[0], 1);
    }
   }
}

[Nicolas S. (Gast)]

Also einen Cast in volatile habe ich noch nie gesehen....

....aber irgendwie fehlen mir hier auch die Deklarationen.

[Max (Gast)]

Das der
>> (0 == (volatile uint8_t)m_cRecBuffer[0])
Teil wegoptimiert wird, könnte vielleicht daran liegen, dass du
m_cRecBuffer nicht als volatile deklariert ist. Das könntest mal 
ausprobieren.
Aber ich weiß auch nich, was ein volatile cast letztlich für 
Auswirkungen hat.

[Peter D. (peda)]

Also beim AVR-GCC läßt sich volatile nicht direkt casten.
Nur über den Umweg als Pointer:

// force access of interrupt variables
#define IVAR(x)         (*(volatile typeof(x)*)&(x))

uint8_t blub;

int main()
{
  if( IVAR(blub) == 0 ){

  }
}

[(prx) A. K. (prx)]

Wenn man auf eine Variable, die nicht als "volatile" deklariert ist, 
erst einmal zugegriffen hat, dann ist es ziemlich egal, ob man den so 
erhaltenen Wert nachträglich zu "volatile" castet. Das ist so, als ob 
man den Stall zusperrt, nachdem das Pferd schon ausgebüxt ist.

[Jörg W. (dl8dtl) (Moderator)]

Anmerkung 92 in Abschnitt “6.5.4 Cast operators” im C-Standard
lautet:

92) A cast does not yield an lvalue. Thus, a cast to a qualified type has
    the same effect as a cast to the unqualified version of the type.

Anders ausgedrückt: das “volatile” im Cast ist an dieser Stelle
wirkungslos.

(Edit: A. K. war schneller.)

[Kindergärtner (Gast)]

Peter Dannegger schrieb:
> Also beim AVR-GCC läßt sich volatile nicht direkt casten.
Genau das ist das Problem. Du liest die *nicht*-volatile Variable 
m_recBuffer aus (kann also wegoptimiert werden) und castest das 
Ergebnis nach "volatile uint8_t".
In C wäre es so richtig:

while (0 == ((volatile uint8_t*)m_cRecBuffer)[0]) {

In C++:

while (0 == const_cast<volatile uint8_t*>(&m_cRecBuffer)[0]) {

(const_cast ist auch für volatile zuständig...)
Natürlich wäre es geschickter, m_cRecBuffer gleich komplett als 
"volatile" zu definieren.

Peter Dannegger schrieb:
> #define IVAR(x)         (*(volatile typeof(x)*)&(x))
Und für die 2 anderen C++-Programmierer hier um Forum:

template <typename T>
inline volatile T& IVAR (T& var) {
  return const_cast<volatile T&>(var);
}

[Jörg W. (dl8dtl) (Moderator)]

Kindergärtner schrieb:
> In C wäre es so richtig:while (0 == ((volatile
> uint8_t*)m_cRecBuffer)[0]) {

Nein, da fehlt ein Adressoperator und eine Dereferenzierung.  Man
kann aber stattdessen auch gleich das Array selbst nehmen:

while (*(volatile uint8_t *)m_cRecBuffer == 0) { ... }

[(prx) A. K. (prx)]

Jörg Wunsch schrieb:
>> In C wäre es so richtig:while (0 == ((volatile
>> uint8_t*)m_cRecBuffer)[0]) {
>
> Nein, da fehlt ein Adressoperator und eine Dereferenzierung.

Genauer hinsehen. ;-)

  ((volatile uint8_t*)m_cRecBuffer)[0]
= impliziter Adressoperator:
  (volatile uint8_t*)m_cRecBuffer
+ Dereferenzierung:
  (...)[0]

[Jörg W. (dl8dtl) (Moderator)]

A. K. schrieb:
> + Dereferenzierung:

Stimmt, die Klammerung war mir entgangen (bzw. das Auge hatte sie
falsch herum sortiert).

[Thomas (Gast)]

Vielen Dank für die ausführlichen Antworten, wieder was gelernt.