Re: build failure? (libgfortran)

2007-02-05 Thread Dorit Nuzman
Grigory Zagorodnev <[EMAIL PROTECTED]> wrote on 05/02/2007 08:18:34: > Dorit Nuzman wrote: > > I'm seeing this bootstrap failure on i686-pc-linux-gnu (revision 121579) - > > something I'm doing wrong, or is anyone else seeing this? > > Yes. I see the same at x86_64-redhat-linux. > Thanks. Turns

Re: gcc-4.1.2 RC1 build problem

2007-02-05 Thread Paolo Bonzini
The macro $(SYSTEM_HEADER_DIR) is used in a double-quoted context, leading to nonportable "...`..."..."...`...", see . Proposed untested patch. (I also haven't checked whether there are other instances of this iss

Re: bugzilla error

2007-02-05 Thread Daniel Berlin
Clear your cookie, try again, and it should fix it. (Sorry, i'm working on the cookie issues. There is something very odd going on) On 2/5/07, Matthias Klose <[EMAIL PROTECTED]> wrote: Got this page, trying to add an attachment to #30706. Matthias This is GCC Bugzilla This is GCC Bugzilla

Re: build failure? (libgfortran)

2007-02-05 Thread Richard Guenther
On 2/5/07, Dorit Nuzman <[EMAIL PROTECTED]> wrote: Grigory Zagorodnev <[EMAIL PROTECTED]> wrote on 05/02/2007 08:18:34: > Dorit Nuzman wrote: > > I'm seeing this bootstrap failure on i686-pc-linux-gnu (revision 121579) - > > something I'm doing wrong, or is anyone else seeing this? > > Yes. I se

Re: GCC 4.1.2 Status Report

2007-02-05 Thread Richard Guenther
On Sun, 4 Feb 2007, Mark Mitchell wrote: > [Danny, Richard G., please see below.] > > Thanks to all who have helped tested GCC 4.1.2 RC1 over the last week. > > I've reviewed the list traffic and Bugzilla. Sadly, there are a fair > number of bugs. Fortunately, most seem not to be new in 4.1.2,

Re: build failure? (libgfortran)

2007-02-05 Thread Bruce Korb
On 2/5/07, Richard Guenther <[EMAIL PROTECTED]> wrote: > > > I'm seeing this bootstrap failure on i686-pc-linux-gnu (revision > 121579) - > > > something I'm doing wrong, or is anyone else seeing this? I *didn't* see it or I would not have committed. This is because we now fixinclude sysmacro

Scheduling an early complete loop unrolling pass?

2007-02-05 Thread Richard Guenther
Hi, currently with -ftree-vectorize we generate for for (i=0; i<3; ++i) # SFT.4346_507 = VDEF # SFT.4347_508 = VDEF # SFT.4348_509 = VDEF d[i] = 0.0; for (j=0; j:; vect_cst_.4501_723 = { 0.0, 0.0 }; vect_p.4506_724 = (vector double *) &D.76822; vect_p.4502_725 = vect_p.45

Re: Scheduling an early complete loop unrolling pass?

2007-02-05 Thread Paolo Bonzini
As we also only vectorize innermost loops I believe doing a complete unrolling pass early will help in general (I pushed for this some time ago). Thoughts? It might also hurt, though, since we don't have a basic block vectorizer. IIUC the vectorizer is able to turn for (i = 0; i < 4; i+

Re: Scheduling an early complete loop unrolling pass?

2007-02-05 Thread Richard Guenther
On Mon, 5 Feb 2007, Paolo Bonzini wrote: > > > As we also only vectorize innermost loops I believe doing a > > complete unrolling pass early will help in general (I pushed > > for this some time ago). > > > > Thoughts? > > It might also hurt, though, since we don't have a basic block vectorizer

Re: Scheduling an early complete loop unrolling pass?

2007-02-05 Thread Jan Hubicka
> > Hi, > > currently with -ftree-vectorize we generate for > > for (i=0; i<3; ++i) > # SFT.4346_507 = VDEF > # SFT.4347_508 = VDEF > # SFT.4348_509 = VDEF > d[i] = 0.0; Also Tomas' patch is supposed to catch this special case and convert it into memset that should be subsequentl

Re: Scheduling an early complete loop unrolling pass?

2007-02-05 Thread Richard Guenther
On Mon, 5 Feb 2007, Jan Hubicka wrote: > > > > Hi, > > > > currently with -ftree-vectorize we generate for > > > > for (i=0; i<3; ++i) > > # SFT.4346_507 = VDEF > > # SFT.4347_508 = VDEF > > # SFT.4348_509 = VDEF > > d[i] = 0.0; > > Also Tomas' patch is supposed to catch this sp

Re: GCC 4.1.2 Status Report

2007-02-05 Thread Daniel Berlin
On 2/4/07, Mark Mitchell <[EMAIL PROTECTED]> wrote: [Danny, Richard G., please see below.] Thanks to all who have helped tested GCC 4.1.2 RC1 over the last week. I've reviewed the list traffic and Bugzilla. Sadly, there are a fair number of bugs. Fortunately, most seem not to be new in 4.1.2,

Re: GCC 4.1.2 Status Report

2007-02-05 Thread Mark Mitchell
Daniel Berlin wrote: >> Daniel, 30088 is another aliasing problem. IIIRC, you've in the past >> said that these were (a) hard to fix, and (b) uncommon. Is this the >> same problem? If so, do you still feel that (b) is true? I'm >> suspicious, and I am afraid that we need to look for a conserva

Re: Scheduling an early complete loop unrolling pass?

2007-02-05 Thread Dorit Nuzman
Richard Guenther <[EMAIL PROTECTED]> wrote on 05/02/2007 18:16:05: > On Mon, 5 Feb 2007, Jan Hubicka wrote: ... > > Did you run some benchmarks? > > Not yet - I'm looking at the C++ SPEC 2006 benchmarks at the moment > and using vectorization there seems to do a lot of collateral damage > (maybe n

Re: Scheduling an early complete loop unrolling pass?

2007-02-05 Thread Dorit Nuzman
Richard Guenther <[EMAIL PROTECTED]> wrote on 05/02/2007 17:59:00: > On Mon, 5 Feb 2007, Paolo Bonzini wrote: > > > > > > As we also only vectorize innermost loops I believe doing a > > > complete unrolling pass early will help in general (I pushed > > > for this some time ago). > > > > > > Though

Re: Scheduling an early complete loop unrolling pass?

2007-02-05 Thread Dorit Nuzman
Hi Richard, Richard Guenther <[EMAIL PROTECTED]> wrote on 05/02/2007 17:27:03: ... > > ... > > and we are later not able to do constant propagation to the > second loop which we can do if we first unroll such small loops. > > As we also only vectorize innermost loops by the way, we are working o

Re: GCC 4.1.2 Status Report

2007-02-05 Thread Richard Guenther
On 2/5/07, Mark Mitchell <[EMAIL PROTECTED]> wrote: Daniel Berlin wrote: >> Daniel, 30088 is another aliasing problem. IIIRC, you've in the past >> said that these were (a) hard to fix, and (b) uncommon. Is this the >> same problem? If so, do you still feel that (b) is true? I'm >> suspiciou

Re: GCC 4.1.2 Status Report

2007-02-05 Thread Mark Mitchell
Richard Guenther wrote: >> > It's certainly true that people will discover more and more aliasing >> > bugs the harder they work 4.1 :) >> >> Do you think that PR 30088 is another instance of the same problem, and >> that therefore turning off the pruning will fix it? > > Disabling pruning will a

ANNOUNCE: Gelato ICE GCC track, San Jose, CA, April 16-18, 2007

2007-02-05 Thread Mark K. Smith
The following GCC track is part of the Gelato ICE (Itanium Conference & Expo) technical program, April 16-18, 2007, San Jose, CA. All interested GCC developers are invited to attend . A working list of speakers and topics can be found here: This year there is a strong focus on Linux. Andrew Morto

Re: Scheduling an early complete loop unrolling pass?

2007-02-05 Thread Zdenek Dvorak
Hello, > >As we also only vectorize innermost loops I believe doing a > >complete unrolling pass early will help in general (I pushed > >for this some time ago). > > > >Thoughts? > > It might also hurt, though, since we don't have a basic block > vectorizer. IIUC the vectorizer is able to turn

RE: testing GCC 4.2 on IA64 using Debian as a test suite <--- correction

2007-02-05 Thread Mark K. Smith
> Eight IA64 specific and 10 generic GCC defects previously unknown > were identified. All these bugs have been reported to the GCC bug > tracker together with test cases and have all been fixed. Correction/clarification: All IA-64 specific bugs have been fixed.

gcc-4.1-20070205 is now available

2007-02-05 Thread gccadmin
Snapshot gcc-4.1-20070205 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20070205/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.1 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches

Re: Scheduling an early complete loop unrolling pass?

2007-02-05 Thread Dorit Nuzman
> Hi Richard, > > ... > However..., > > I have seen cases in which complete unrolling before vectorization enabled > constant propagation, which in turn enabled significant simplification of > the code, thereby, in fact making a previously unvectorizable loop (at > least on some targets, due to the