auto vectorization - should this work ?

[Gianni Mariani]

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 -S -O3 -ftree-vectorize -ftree-vectorizer-verbose=6 -m32 -msse3 
xxx_optimizer.c


xxx_optimizer.c:16: note: not vectorized: can't determine dependence 
between s_5->a[i_16] and s_5->a[i_16]

xxx_optimizer.c:16: note: vectorized 0 loops in function.


It appears to not ...

Re: including PR summary in gcc-cvs commit mails

[Andreas Schwab]

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 bugzilla).  This
> would allow people to find the checkins that interest them without
> having to open each and every one in bugzilla.

You can search for list of specific bug numbers, or directly use
, where PRS is a
comma separated list of bug numbers.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: libjava Divide_1 and pr6388 fail on 4.2.0 RC3 for several targets

[Andrew Haley]

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 interval.  I 
 > > leave it as an exercise to the reader to determine which could have 
 > > precipitated this problem.
 > >
 > > $ svn log -r 124328:124356
 > > 
 > > r124331 | jsm28 | 2007-05-01 10:39:16 -0700 (Tue, 01 May 2007) | 2 lines
 > >
 > >* config/rs6000/libgcc-ppc-glibc.ver (__gcc_qgt): Fix typo.
 > >
 > > 
 > > r124338 | ian | 2007-05-01 12:23:47 -0700 (Tue, 01 May 2007) | 13 lines
 > >
 > >PR tree-optimization/31739
 > >* tree-vrp.c (vrp_val_is_max): New static function.
 > >(vrp_val_is_min): New static function.
 > >(set_value_range_to_value): Use TYPE_{MAX,MIN}_VALUE rather than
 > >copying the node.
 > >(set_value_range): Use vrp_val_is_{max,min}.
 > >(extract_range_from_assert): Likewise.
 > >(extract_range_from_binary_expr): Likewise.
 > >(extract_range_from_unary_expr): Likewise.
 > >(dump_value_range, vrp_meet): Likewise.
 > >(vrp_visit_phi_node): Likewise.
 > >* tree.c (build_distinct_type_copy): Revert change of 2007-04-27.
 > >
 > > 
 > >
 > > I will build x86_64-pc-linux-gnu before and after r124338
 > >
 > This is now: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31842

According to
http://gcc.gnu.org/ml/gcc-testresults/2007-05/msg00132.html, this bug
isn't manifested on x86_64, either.  So, I have no hardware on which I
can test the problem today.

Ian, a clue: The Java test that's failing makes sure that a divide
overflow trap is caught and turned into the correct exception.  

Andrew.

Re: libjava Divide_1 and pr6388 fail on 4.2.0 RC3 for several targets

[Eric Botcazou]

> 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 instead.

-- 
Eric Botcazou

RE: Successful build of GCC 4.2.0 RC3 on latest Cygwin snapshot 20070427

[Dave Korn]

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 finished in another day or so...  :-O


[ Note to self: never run make check with CYGWIN=error_start=insight.  D'oh! ]

cheers,
  DaveK
-- 
Can't think of a witty .sigline today

Re: GCC 4.2.0 RC3 Available

[Richard Guenther]

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 of what is specified with @samp{--enable-checking} the
> +stage1 compiler is built with checking enabled.  For small or slow
> +systems you can disable checking for stage1 using
> [EMAIL PROTECTED]

Minor editing:

"By default, the Stage 1 compiler is built with checking enabled, even
if @option{--disable-checking} is used.  If your system is too slow or
too small to bootstrap the compiler with checking enabled, you can use
@option{--disable-stage1-checking} to disable checking for the Stage 1
compiler."

Note, in particular, that you should use @option rather than @samp.

This patch is OK for 4.2 and mainline, assuming that someone verifies
that the switch actually performs as advertised.


I have verified that on the branch

- without any checking option defined we build stage1 with checking=yes
  and further stages with release checking
- with --enable-checking=release we build all stages with release checking
- with --disable-stage1-checking we build stage1 with --disable-checking
  and further stages with release checking
- with --enable-stage1-checking=release we build stage1 with release checking

So,

2007-05-05  Richard Guenther  <[EMAIL PROTECTED]>

   * doc/install.texi (--enable-checking): Mention different
   default for stage1.
   (--enable-stage1-checking): Document.


disables1c
Description: Binary data

Re: libjava Divide_1 and pr6388 fail on 4.2.0 RC3 for several targets

[Andrew Haley]

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.org/ml/gcc-testresults/2007-05/msg00093.html instead.
 
Oh, dear.  Unfortunately, I'm going to be away from my computer for
about 48hrs...

Andrew.

Re: auto vectorization - should this work ?

[Ira Rosen]

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 by comparing the trees (which are pointers) and not their content.

I'll look into this and, I hope, I will submit a fix for that soon (I guess
using operand_equal_p instead).

Thanks,
Ira

Re: auto vectorization - should this work ?

[Toon Moene]

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_differ_p(), we do
that by comparing the trees (which are pointers) and not their content.

I'll look into this and, I hope, I will submit a fix for that soon (I guess
using operand_equal_p instead).


I hope it helps - we have a lot of them resulting from fairly innocent 
Fortran.


I'd be willing to test out your solution privately, if you prefer such a 
round first ...


Thanks.

--
Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
At home: http://moene.indiv.nluug.nl/~toon/
Who's working on GNU Fortran: 
http://gcc.gnu.org/ml/gcc/2007-01/msg00059.html

Re: auto vectorization - should this work ?

[Ira Rosen]

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

Re: auto vectorization - should this work ?

[Richard Guenther]

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 and s_5->a) in base_object_differ_p(), we do
that by comparing the trees (which are pointers) and not their content.

I'll look into this and, I hope, I will submit a fix for that soon (I guess
using operand_equal_p instead).


Duh, that function looks interesting, indeed ;)

It should probably use get_base_address () to get at the base object
and then operand_equal_p to compare them.  Note that it strips outer
variable offset as well, like for a[i].b[j] you will get 'a' as the base object.
If data-ref cannot handle this well, just copy get_base_address () and
stop at the first ARRAY_REF you come along.  But maybe
base_object_differ_p is only called from contexts that are well-defined
in this regard.

Richard.

Re: auto vectorization - should this work ?

[Ira Rosen]

"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 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 by comparing the trees (which are pointers) and not their content.
> >
> > I'll look into this and, I hope, I will submit a fix for that soon (I
guess
> > using operand_equal_p instead).
>
> Duh, that function looks interesting, indeed ;)
>
> It should probably use get_base_address () to get at the base object
> and then operand_equal_p to compare them.  Note that it strips outer
> variable offset as well, like for a[i].b[j] you will get 'a' as the
> base object.
> If data-ref cannot handle this well, just copy get_base_address () and
> stop at the first ARRAY_REF you come along.  But maybe
> base_object_differ_p is only called from contexts that are well-defined
> in this regard.

base_object_differ_p is called after the data-refs analysis. So we really
compare base objects here, and no further peeling is needed at this stage.
At least, that was our intention.

Thanks,
Ira

>
> Richard.

Re: Successful build of GCC 4.2.0 RC3 on latest Cygwin snapshot 20070427

[Aaron Gray]

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 finished in another day or so...  :-O


[ Note to self: never run make check with CYGWIN=error_start=insight. 
D'oh! ]


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 missed it earlier when first 
building but on rebuilding have captured it in a log file for thurther 
examination.


I can put together a test example if required.

Report back if I find anything thurther.

Aaron

RE: Successful build of GCC 4.2.0 RC3 on latest Cygwin snapshot 20070427

[Dave Korn]

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 missed it earlier when first
> building but on rebuilding have captured it in a log file for thurther
> examination.

  IIUIC, the visibility attribute is only relevant to ELF targets, which
cygwin is not.  Hence the warnings, while seemingly redundant, are at least
accurate[*].  The visibility attribute needs wrapped in a macro that can be
undef'd on non-ELF systems.

> I can put together a test example if required.

  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..

cheers,
  DaveK

[*] - and without seeing the actual code I don't even know that there aren't
that many attributed decls on the same line...
-- 
Can't think of a witty .sigline today

RE: Successful build of GCC 4.2.0 RC3 on latest Cygwin snapshot 20070427

[Dave Korn]

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..

Filed as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31844.


cheers,
  DaveK
-- 
Can't think of a witty .sigline today

Re: Successful build of GCC 4.2.0 RC3 on latest Cygwin snapshot 20070427

[Aaron Gray]

- 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, 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..


Filed as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31844.


It was on struct's or classes, I have not checked it but I think it but 
inheritance maybe the culprit.


Aaron

Re: Expression with 2 operations

[Sebastian Pop]

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_stmts failed
"


[...]



This is the debug_tree() of new_rhs :
 
unit size 
align 32 symtab 0 alias set 3 canonical type 0x403532d8
precision 32 min  max 
pointer_to_this >

arg 0 

arg 0 



You are in gimple form, so you have to build 3-address code: with temporary
variables, you want for "foo(a + i * x)" the following code:

t0 = i * x
t1 = a + t0
foo (t1)

I hope this helps you solving the ICEs that you saw,
Sebastian

Re: New wiki page on testing compile times and memory usage

[Gerald Pfeifer]

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?

Gerald

Index: index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/benchmarks/index.html,v
retrieving revision 1.20
diff -u -3 -p -r1.20 index.html
--- index.html  18 Feb 2007 22:15:18 -  1.20
+++ index.html  6 May 2007 22:13:52 -
@@ -52,7 +52,7 @@ Statistics about GCC code size for sever
 Environment (CSiBE), along with the testbed and measurement scripts.
 
 
-Related benchmarks
+Related benchmarks and scripts
 
 
 Charles Leggett runs several benchmarks (Bench++, Haney, Stepanov, OOPACK)
@@ -86,6 +86,11 @@ summaries are available at http://www.suse.de/~gcctest/memory/";>http://www.suse.de/~gcctest/memory/
 
 
+
+Diego Novillo compiled a collection of relevant scripts at
+http://gcc.gnu.org/wiki/PerformanceTesting";>http://gcc.gnu.org/wiki/PerformanceTesting
+
+
 Openbench
 
 

Re: RFC: obsolete __builtin_apply?

[Andrew Pinski]

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,
Andrew Pinski