Should the vectorizer optimizer do the right thing with this :
typedef float real;
typedef struct A
{
real a[1000];
real b[1000];
} __attribute__ ((aligned (16))) A;
void foo( A * const s )
{
int i;
for ( i=0; i<1000; ++i)
{
s->a[i]=100*s->a[i]+300*s->b[i];
}
}
gcc
Ryan Hill <[EMAIL PROTECTED]> writes:
> Hello. I have a question regarding the svn logs that get sent to the
> gcc-cvs mailing list on every commit. I was wondering if it would be
> possible for those mails that contain a PR number to also include the
> title of that PR (ie. the contents of in
David Daney writes:
>> I was hoping that 4.2.0 would be good, but very recently someone
> >> broke it. Don't people test for regressions before committing?
> > According to the testresults list, this broke between r124328 and
> > r124356. There were two commits to the branch in that interva
> According to
> http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg00132.html, this bug
> isn't manifested on x86_64, either.
Wrong choice, this is the 4.1 branch.
> So, I have no hardware on which I can test the problem today.
See http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg00093.html inste
On 06 May 2007 07:15, Aaron Gray wrote:
> I have successfully built GCC-4.2.0-20070501 on latest Cygwin snapshot
> 20070427.
>
> GCC 4.2.0 RC3 is available from:
>
> ftp://gcc.gnu.org/pub/gcc/prerelease-4.2.0-20070501
>
> I have not done run the testsuite ( make check)
I'm doing tha
On 5/6/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
Richard Guenther wrote:
> 2007-05-05 Richard Guenther <[EMAIL PROTECTED]>
>
>* doc/install.texi (--disable-stage1-checking): Document.
> [EMAIL PROTECTED] --disable-stage1-checking
> [EMAIL PROTECTED] [EMAIL PROTECTED]
> +Regardless
Eric Botcazou writes:
> > According to
> > http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg00132.html, this bug
> > isn't manifested on x86_64, either.
>
> Wrong choice, this is the 4.1 branch.
>
> > So, I have no hardware on which I can test the problem today.
>
> See http://gcc.gnu.o
Yes, this should get vectorized. The problem is in data dependencies
analysis. We fail to prove that s_5->a[i_16] and s_5->a[i_16] access the
same memory location. I think, it happens since when we compare the bases
of the data references (s_5->a and s_5->a) in base_object_differ_p(), we do
that b
Ira Rosen wrote:
Yes, this should get vectorized. The problem is in data dependencies
analysis. We fail to prove that s_5->a[i_16] and s_5->a[i_16] access the
same memory location. I think, it happens since when we compare the bases
of the data references (s_5->a and s_5->a) in base_object_diffe
Toon Moene <[EMAIL PROTECTED]> wrote on 06/05/2007 15:33:38:
> I'd be willing to test out your solution privately, if you prefer such a
> round first ...
>
Thanks. I'll send you a patch when it's ready.
Ira
On 5/6/07, Ira Rosen <[EMAIL PROTECTED]> wrote:
Yes, this should get vectorized. The problem is in data dependencies
analysis. We fail to prove that s_5->a[i_16] and s_5->a[i_16] access the
same memory location. I think, it happens since when we compare the bases
of the data references (s_5->a a
"Richard Guenther" <[EMAIL PROTECTED]> wrote on 06/05/2007
16:17:05:
> On 5/6/07, Ira Rosen <[EMAIL PROTECTED]> wrote:
> >
> > Yes, this should get vectorized. The problem is in data dependencies
> > analysis. We fail to prove that s_5->a[i_16] and s_5->a[i_16] access
the
> > same memory locatio
On 06 May 2007 07:15, Aaron Gray wrote:
I have successfully built GCC-4.2.0-20070501 on latest Cygwin snapshot
20070427.
GCC 4.2.0 RC3 is available from:
ftp://gcc.gnu.org/pub/gcc/prerelease-4.2.0-20070501
I have not done run the testsuite ( make check)
I'm doing that. Should be f
On 06 May 2007 14:37, Aaron Gray wrote:
> On the LLVM build I am getting multiple :-
>
> warning: visibility attribute not supported in this configuration;
> ignored
>
> with the same line number, eight or so in some cases but usually two.
>
> Have not looked into this properly yet, I misse
On 06 May 2007 15:54, Dave Korn wrote:
[ Cygwin list snipped from CC line: not relevant there. ]
>
> If you can produce once that shows excess warnings being emitted, yes,
> that would be worth filing a PR. Hmm, a quick test I couldn't get excess
> ones, but the line numbers all look wrong..
- Original Message -
From: "Dave Korn" <[EMAIL PROTECTED]>
To: "'Dave Korn'" <[EMAIL PROTECTED]>; "'Aaron Gray'" <[EMAIL PROTECTED]>
Cc: "'GCC'"
Sent: Sunday, May 06, 2007 4:10 PM
Subject: RE: Successful build of GCC 4.2.0 RC3 on latest Cygwin snapshot
20070427
On 06 May 2007 15:54,
Hi,
Antoine Eiche <[EMAIL PROTECTED]> wrote:
Why can I not do "foo(a + i * x)" then I can do "foo(i * x)" ou "foo(a + i)" ?*
[...]
When a try to compile a program gcc answer:
"
tab.c:22: erreur: invalid operand to binary operator
i_28 * 4;
tab.c:22: erreur interne du compilateur: verify_stm
On Thu, 12 Apr 2007, Diego Novillo wrote:
> I've added a collection of scripts that I have gathered over time to
> test compile time and memory usage when making changes to the compiler.
>
> http://gcc.gnu.org/wiki/PerformanceTesting
Nice, thanks for sharing these. How about the patch below?
Ge
On 4/27/07, Steve Ellcey <[EMAIL PROTECTED]> wrote:
Andrew, are you still planning on applying the libobjc patch that
removes the use of __builtin_apply?
Yes it is still on my list. I have been working on other GCC work this
last couple of weeks, I might be able to get it next weekend.
Thanks
19 matches
Mail list logo
