> 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
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
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
>
> 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
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
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
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
> -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
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
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
10 matches
Mail list logo
