Re: Query regarding volatiles and store CCP.

5 msg	Failing matrix tests
22 msg	Host/Target confusion in Dwarf output
2 msg	Major Differences between gcc4.2 and gcc3.3
1 msg	New bootstrap failure ppc64
3 msg	GDB testsuite + dejagnu uses gcc compiler by de...
2 msg	Bootstrap broken on trunk rev. 126573
171 msg	RFH: GPLv3
5 msg	Test gcc.c-torture/execute/align-3.c
1 msg	[Fwd: error in libfortran on cygwin]
1 msg	Andreas Krebbel appointed s390 co-maintainer
2 msg	-fstrict-overflow example 4.2 status
6 msg	GCC 4.2.1 Status Report (2007-07-10)
7 msg	ICE building libgcc2.c for MIPS, too
1 msg	new events at GCC Summit
2 msg	ICE while bootstraping on ppc64.
2 msg	RFA: upcoming testsuite disruptions
6 msg	ODR violation for std::cout etc.

Query regarding volatiles and store CCP.
\ Ramana Radhakrishnan (10 Jul 2007)
. \ Richard Guenther (10 Jul 2007)
. . \ Ramana Radhakrishnan (10 Jul 2007)

3 msg	missing 'std::move'
3 msg	crtbegin.o crtend.o

Subject:	Re: Query regarding volatiles and store CCP.
Group:	Gcc
From:	Ramana Radhakrishnan
Date:	10 Jul 2007

Hi Richard,

On 7/10/07, Richard Guenther <richard.guenther> wrote:
> On 7/10/07, Ramana Radhakrishnan <ramana.r> 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