Question

EDITED and refined my question after Johannes’s valuable answer

bool b = true;
volatile bool vb = true;    
void f1() { }
void f2() { b = false; }

void(* volatile pf)() = &f1; //a volatile pointer to function

int main()
{
   //different threads start here, some of which may change pf 
   while(b && vb)
   {
      pf();
   }
}

So, let’s forget synchronization for a while. The question is whether b has to be declared volatile. I have read the standard and sort-of know the formal definition of volatile semantics (I even almost understand them, the word almost being the key). But let’s be a bit informal here. If the compiler sees that in the loop there is no way for b to change then unless b is volatile, it can optimize it away and assume it is equivalent to while(vb). The question is, in this case pf is itself volatile, so is the compiler allowed to assume that b won’t change in the loop even if b is not volatile?

Please refrain from comments and answers which address the style of this piece of code, this is not a real-world example, this is an experimental theoretical question.
Comments and answers which, apart from answering my question, also address the semantics of volatile in greater detail which you think I have misunderstood are very much welcome.

I hope my question is clear. TIA

Editing once more:
what about this?

bool b = true;
volatile bool vb = true;
void f1() {}
void f2() {b = false;}
void (*pf) () = &f1;

#include <iosrteam>
int main()
{
   //threads here

   while(b && vb)
   {
      int x;
      std::cin >> x;
      if(x == 0)
         pf = &f1;
      else
         pf = &f2;    
      pf();
   } 
}

Is there a principal difference between the two programs. If yes, what is the difference?

Answer 1

The question is, in this case pf is itself volatile, so is the compiler allowed to assume that b won’t change in the loop even if b is not volatile?

It can’t, because you say that pf might be changed by the other threads, and this indirectly changes b if pf is called then by the while loop. So while it is theoretically not required to read b normally, it in practice must read it to determine whether it should short circuit (when b becomes false it must not read vb another time).

---

Answer to the second part

In this case pf is not volatile anymore, so the compiler can get rid of it and see that f1 has an empty body and f2 sets b to false. It could optimize main as follows

int main()
{
   // threads here (which you say can only change "vb")

   while(vb)
   {
      int x;
      std::cin >> x;
      if(x != 0)
         break;    
   } 
}

---

Answer to older revision

One condition for the compiler to be allowed to optimize the loop away is that the loop does not access or modify any volatile object (See [stmt.iter]p5 in n3126). You do that here, so it can’t optimize the loop away. In C++03 a compiler wasn’t allowed to optimize even the non-volatile version of that loop away (but compilers did it anyway).

Note that another condition for being able to optimize it away is that the loop contains no synchronization or atomic operations. In a multithreaded program, such should be present anyway though. So even if you get rid of that volatile, if your program is properly coded I don’t think the compiler can optimize it away entirely.