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)
