Re: Does unrolling prevents doloop optimizations?

2007-06-30 Thread Ayal Zaks
Zdenek Dvorak <[EMAIL PROTECTED]> wrote on 30/06/2007 09:55:45: > Hello, > > > By "this change" I mean just commenting out the check in > > doloop_condition_get. After applying the patch that introduced DOLOOP > > patterns for SPU (http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01470.html) > > we ne

Re: Does unrolling prevents doloop optimizations?

2007-06-30 Thread Zdenek Dvorak
Hello, > It doesn't seem that the number of iterations analysis from loop-iv.c deals > with EQ closing branches. loop-iv works just fine for EQ closing branches. Zdenek > One option is for sms to use > doloop_condition_get/loop-iv analysis in their current form, and if failed > check (on our ow

Re: GCC 4.3.0 Status Report (2007-06-29)

2007-06-30 Thread Andreas Meier
Hello Mark Mitchell schrieb: At this point, there are 153 P3 and higher regressions open against GCC 4.3.0. In reviewing those, I was struck by how many are in fact new regressions in 4.3 -- problems that did not occur in previous releases. These include a number of P1 problems such as:

Re: Does unrolling prevents doloop optimizations?

2007-06-30 Thread Ayal Zaks
Zdenek Dvorak <[EMAIL PROTECTED]> wrote on 30/06/2007 10:52:32: > Hello, > > > It doesn't seem that the number of iterations analysis from loop-iv.c deals > > with EQ closing branches. > > loop-iv works just fine for EQ closing branches. > Thanks for the clarification (I didn't see EQ in iv_numbe

Re: Does unrolling prevents doloop optimizations?

2007-06-30 Thread Zdenek Dvorak
Hello, > Since we didn't fail on assert in doloop_modify despite the hack in > doloop_condition_get (removal of the condition check), I just restored the > doloop_condition_get to it's original state and defined instead a new > function called sms_condition_get which is a copy of doloop_condition_

Re: Does unrolling prevents doloop optimizations?

2007-06-30 Thread Zdenek Dvorak
Hello, > > > It doesn't seem that the number of iterations analysis from loop-iv.c > deals > > > with EQ closing branches. > > > > loop-iv works just fine for EQ closing branches. > > > > Thanks for the clarification (I didn't see EQ in iv_number_of_iterations's > switch (cond)). that is because

Re: PATCH: Regenerate aclocal.m4 and Makefile.in

2007-06-30 Thread H.J. Lu
On Sat, Jun 30, 2007 at 07:26:52PM +0200, Andreas Schwab wrote: > "H.J. Lu" <[EMAIL PROTECTED]> writes: > > > aclocal.m4 wasn't generated with libtool.md in top dir and > > There should not be any copy of libtool.m4 in aclocal.m4, since it is > already included via m4_include. If you look at lib

Re: Does unrolling prevents doloop optimizations?

2007-06-30 Thread Ayal Zaks
Zdenek Dvorak <[EMAIL PROTECTED]> wrote on 30/06/2007 20:36:12: > Hello, > > > > > It doesn't seem that the number of iterations analysis from loop-iv.c > > deals > > > > with EQ closing branches. > > > > > > loop-iv works just fine for EQ closing branches. > > > > > > > Thanks for the clarificati

Re: PATCH: Regenerate aclocal.m4 and Makefile.in

2007-06-30 Thread Andreas Schwab
"H.J. Lu" <[EMAIL PROTECTED]> writes: > On Sat, Jun 30, 2007 at 07:26:52PM +0200, Andreas Schwab wrote: >> Please make sure that you have the right version of libtool installed >> before running aclocal. > For reason, aclocal.m4 always has AM_PROG_LIBTOOL from the installed > libtool.m4. Does any

Fortran regressions

2007-06-30 Thread Daniel Berlin
Apparently there are some fortran regressions caused by my patch. The last time I modified the patch (which was before the freeze), I did a test of C, C++, Fortran, objc. After the freeze ended, I did an svn update in that tree, bootstrapped and regtested c/c++, and committed it. Other than the