On Mon, 21 Oct 2013, matthew green wrote:
> #define raise_ipi(cpi,lvl) do { \ >- volatile int x; \ >+ int x; \ > (cpi)->intreg_4m->pi_set = PINTR_SINTRLEV(lvl); \ >- x = (cpi)->intreg_4m->pi_pend; \ >+ x = (cpi)->intreg_4m->pi_pend; __USE(x); \ > } while (0)I think that the change from the use of volatile to the use of __USE() is a change from reliance on the C standard's guarantee that the memory location behind (cpi)->intreg_4m->pi_pend really will be accessed, to a reliance on what a particular compiler happens to do in this situation.the volatile applies to the access to pi_pend, which is marked a volatile (via the whole intreg_4m pointer.)
Oh, if cpi, or intreg_4m, or pi_pend, is volatile, then it's fine, and that would be the best way to deal with the issue. In such a case, there's no need to use x at all.
i'm not sure that "volatile int x;" actually means anything useful. it's pointer accesses that matter. i could be wrong; volatile is a pretty tricky area.
Yes, the pointer access is the thing that really needs to be volatile, but I previously thought that it was not, and then I thought (incorrectly, I now believe) that making x volatile would be sufficient.
certainly, the generated code is fine (and in most cases, identical).
My concern was with other compilers in the future. If the pointer access is volatile, then I think it's fine.
--apb (Alan Barrett)