RE: A case exposing code sink issue

2011-11-23 Thread Jiangning Liu
One more question... Can " i = i.6_18;" be sinked out of loop, because it doesn't have memory dependence with others? Thanks, -Jiangning > -Original Message- > From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of > Jiangning Liu > Sent: Thursday, November 24, 2011 2:57

RE: A case exposing code sink issue

2011-11-23 Thread Jiangning Liu
Sorry, I realize we can't do that optimization because a_p may have dependence upon other memory accesses like MEM[(int *)&a][D.2248_7]. For example, if it happens a_p equals &a_p, that optimization would be wrong. But can alias analysis solve the problem if we can guarantee (i+(1< -Original

RE: A case exposing code sink issue

2011-11-23 Thread Jiangning Liu
> -Original Message- > From: Andrew Pinski [mailto:pins...@gmail.com] > Sent: Thursday, November 24, 2011 12:15 PM > To: Jiangning Liu > Cc: gcc@gcc.gnu.org > Subject: Re: A case exposing code sink issue > > On Wed, Nov 23, 2011 at 8:05 PM, Jiangning Liu > wrote: > > If this is the root

Re: A case exposing code sink issue

2011-11-23 Thread Andrew Pinski
On Wed, Nov 23, 2011 at 8:05 PM, Jiangning Liu wrote: > If this is the root cause, which optimization pass in GCC take the role to > sink them out of loop? How should we get it fixed? lim1 handles the case just fine for me. lim1 is the first loop pass. After lim1 I get: : # i.1_34 = PHI D

A case exposing code sink issue

2011-11-23 Thread Jiangning Liu
Hi, For this small test case, int a[512] ; int b[512] ; int *a_p ; int *b_p ; int i ; int k ; int f(void) { for( k = 1 ; k <= 9 ; k++) { for( i = k ; i < 512 ; i += k) { a_p = &a[i + (1<: k = 1; : # k.0_9 = PHI i = k

Jumatatea ta te asteapta

2011-11-23 Thread Amandoi
Daca nu ti-ai gasit inca jumatatea, este pentru ca nu ai cautat-o unde trebuie. Ea te asteapta pe http://www.Amandoi.net ATENTIE :In conformitate cu legea 365/2002 cu modificarile aduse prin legea 121/2006 privind comertul elect

Re: Yet another issue with gcc current trunk with ada on cygwin: s-tpoaal.adb:60:13: "Specific" is undefined (more references follow)

2011-11-23 Thread Christian Joensson
> > Try adding defined (__CYGWIN__) to the first line. > done, the new issue is this: /usr/local/src/trunk/objdir.withada/./gcc/xgcc -B/usr/local/src/trunk/objdir.withada/./gcc/ -B/usr/i686-pc-cygwin/bin/ -B/usr/i686-pc-cygwin/lib/ -isystem /usr/i686-pc-cygwin/include -isystem /usr/i686-pc-cygwin

Re: GCC 4.6 is inserting unnecessary MOVAPS instructions for SSE intrinsics

2011-11-23 Thread Marc Glisse
On Wed, 23 Nov 2011, Leith Bade wrote: I have been hand optimising a loop that GCC 4.6 was not able to vectorise. I have been keeping an eye on the assembly output of this loop and have noticed GCC inserting unnecessary MOVAPS instructions. Yes, there are several bugzilla entries showing that

Re: success building gcc-4.6.2 on x86_64-apple-darwin11.2.0

2011-11-23 Thread Jonathan Wakely
On 23 November 2011 03:06, Alex J. Avriette wrote: > > Oh, one last thing, the environment had to be set correctly. I had > mpc, mpfr, and gmp in /usr/local, and the following environment > variables needed to be set for the compile to work: > ABI=64 > CONFIG_SHELL=sh (NOT! bash) > ARCH=x86-64 > CF

Re: Yet another issue with gcc current trunk with ada on cygwin: s-tpoaal.adb:60:13: "Specific" is undefined (more references follow)

2011-11-23 Thread Eric Botcazou
> phew, beyond my abilities yet again. someone more cygwin knowledgable > would need to look into that I suppose... Try adding defined (__CYGWIN__) to the first line. -- Eric Botcazou