On Wed, Aug 8, 2012 at 10:08 PM, Shweta Gupta <er.shwetagupta.edu@xxxxxxxxx> wrote: > The previous output of shed2 contains typing mistake, So the updated output > of shed2: > r3=[ar6-0x34] > [ar2++]=r3 > r2=[ar6-0x30] > [ar2++]=r2 > r1=[ar6-0x2c] > [ar2++]=r1 > I have use –fno-strict-aliasing command line option when compiling test case > but not change in output of shed2 > ./cc1.exe -O2 -frename-registers -fschedule-insns -fno-strict-aliasing > -fdump-rtl-all /cygdrive/d/test.c > > I have also use –fstrict-aliasing command line option but not change in > sched2 output > ./cc1.exe -O2 -frename-registers -fschedule-insns -fstrict-aliasing > -fdump-rtl-all /cygdrive/d/test.c You didn't show us the source code, but this is not necessarily a case that -fstrict-aliasing will affect. If the two pointers have the same type, then it doesn't matter whether you use -fstrict-aliasing or not. A store through a int* pointer can change the value read from a int* pointer. The compiler can only move the read before the store if it can prove that the pointers do not point to the same part of memory. You haven't showed us any source code, so I don't know whether this is a possible problem or not. I'm just suggesting it as the first path of investigation. You are most likely going to have to dig into the compiler data structures to find out what is going on. You're unlikely to get a quick answer on this mailing list. Sorry. Ian
