>Hi,>>>No. const == never changes.>>get_TR changes if a task calls schedule, and return on another cpu.>>>>Yes, I found this exact problem on ppc64 where we would cache the>processor data area across a schedule(). What was interesting was that>__attribute__ ((pure)) was not enough to fix this.>>static inline struct Paca *get_paca(void) __attribute__ ((pure));>static inline struct Paca *get_paca(void)>{> struct Paca *rval;> __asm__ ("mfspr %0,0x113" : "=r" (rval));> return rval;>}>>Alan Modra came to the rescue and found that gcc was optimising too much>and since the function did not touch any global variables, it would>upgrade the pure to const. This was on gcc 3.0.X.>But the function called schedule - mustn't gcc assume that schedule writes into global variables?As far as I can see that sounds like a gcc bug.

Could you try how many get_cpu calls are generated by the attached testapp?the i386 RH compilers generate correct code:gcc-2.96-98: 4 calls.gcc3-3.0.1-3: 2 calls.