Query regarding volatiles and store CCP.

[Ramana Radhakrishnan]

Hi Richard,



On 7/10/07, Richard Guenther <richard.guenther@gmail.com> wrote:
> On 7/10/07, Ramana Radhakrishnan <ramana.r@gmail.com> wrote:
> > Hi,
> >
> > While upgrading a port of mine to trunk for a testcase I noticed the
> > following . Its more of a question for a language lawyer I guess.
> >
> > The test looks like this.
> >
> > int spinlock[2];
> >
> > void foo (void)
> > {
> > volatile int * spinlock0;
> >
> > while (*spinlock0 == 0)
> > {
> > /* do nothing */
> > }
> > }
> >
> > Store CCP folds away the assignment in the following way :
> >
> >
> > Folded statement: *spinlock0_1 = 0;
> >             into: spinlock[0] = 0;
> >
> > Folded statement: *spinlock1_2 = 0;
> >             into: spinlock[1] = 0;
> >
> > Folded statement: D.1498_3 = *spinlock0_1;
> >             into: D.1498_3 = spinlock[0];
> >
> > main ()
> > {
> >   volatile int * spinlock1;
> >   volatile int * spinlock0;
> >   int D.1498;
> >
> > <bb 2>:
> >   spinlock0_1 = &spinlock[0];
> >   spinlock1_2 = &spinlock[1];
> >   spinlock[0] = 0;
> >   spinlock[1] = 0;
> >
> > <bb 3>:
> >   D.1498_3 = spinlock[0];
> >   if (D.1498_3 != 0)
> >     goto <bb 3>;
> >   else
> >     goto <bb 4>;
> >
> > <bb 4>:
> >   return;
> >
> > }
> >
> > which later results in the loop getting optimized away. However
> > marking spinlock as volatile let the loop remain.
> >
> >
> > I originally thought this to be a problem . However after chatting
> > about it on IRC I wasn't sure if this was (un)defined behaviour.   I
> > looked through the standard but was unable to figure out from the
> > prose , whether it stated some place that the object pointed to also
> > should also have the same type qualifiers as the pointer being used to
> > access this.
>
> We usually try hard to keep this working (the testcase above is not complete
> for sure).


Ah yes, I'd missed out an assignment . void foo (void)
> > {
> > volatile int * spinlock0;

Should be volatile int *spinlock0 = &spinlock[0];
}

Filed as PR 32721.

cheers
Ramana


>
> Richard.
>


-- 
Ramana Radhakrishnan