Giovanni Bajo wrote:
Jeffrey A Law <[EMAIL PROTECTED]> wrote:
In fact, after the subversion conversion is over, we can "svn
delete" all those merging tags for good since they're there because
you can't delete them in CVS but we really don't need them anymore
(before anybody asks: "svn delet
Steven Bosscher wrote:
Als je wil, kan ik wel een handje helpen door e.e.a. te analyzeren
voordat je de problemen voorlegt aan de mailing-list.
Erg interessant, als dit werkt. Gaat het KNMI ook daadwerkelijk
gfortran gebruiken of zijn we nog lang niet ver genoeg daarvoor?
For [EMAIL PROTECTED
On Oct 22, 2005 09:34 PM, Steven Bosscher <[EMAIL PROTECTED]> wrote:
>
Some stuff that, needless to say, was in Dutch and intended for Toon
only.
Sorry,
Gr.
Steven
Als je wil, kan ik wel een handje helpen door e.e.a. te analyzeren
voordat je de problemen voorlegt aan de mailing-list.
Erg interessant, als dit werkt. Gaat het KNMI ook daadwerkelijk
gfortran gebruiken of zijn we nog lang niet ver genoeg daarvoor?
Gr.
Steven
On Oct 21, 2005 09:49 PM, Toon M
I have spent the last couple of hours groking code and I am coming up
empty on this one. I ran into this problem when trying to build the
'tst-tls10' test program from glibc. This is not a glibc problem, rather
an issue with my library and kernel header files, I think. I have ported
NPTL support f
SVN killed my machine (just kidding). But my machine is dead so
I will not able to commit my patches which were approved or approved
in the next couple of days.
I will still be able to check my email and look at some bugzilla stuff
but not as much as before. Hopefully I can get my machine fixed
Snapshot gcc-4.1-20051022 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20051022/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 CVS branch
with the following options: -D2005-10-22 17:43 UTC
You'll
Jeffrey A Law <[EMAIL PROTECTED]> wrote:
>> In fact, after the subversion conversion is over, we can "svn
>> delete" all those merging tags for good since they're there because
>> you can't delete them in CVS but we really don't need them anymore
>> (before anybody asks: "svn delete" keeps history
On Friday 21 October 2005 09:51, Toon Moene wrote:
> So where does the compiler lose this valuable information ?
>
Toon, could you open PRs for these problems? Some of the failures you
see
look like aliasing problems. It'd be nice to have them in bugzill
This one gets vectorized for me, on powerpc-linux:
~/mainline_cvs/bin/gfortran -O3 -ftree-vectorize -maltivec
-ftree-vectorizer-verbose=4 -S hilaram4.f90
hilaram4.f90:4: note: Alignment of access forced using peeling.
hilaram4.f90:4: note: Vectorizing an un
This one does get vectorized with autovect-branch:
[ example with source and destination array exactly overlapping ]
~/autovect_cvs/bin/gfortran -O3 -ftree-vectorize -maltivec
-ftree-vectorizer-verbose=4 -S hilaram1.f90
hilaram1.f90:5: note: dependence distance
L.S.,
Using the autovect branch compiler:
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --prefix=/usr/vec --disable-nls
--disable-multilib --enable-languages=f95
Thread model: posix
gcc version 4.1.0 20051022 (experimental)
I now get the following
On Sat, 2005-10-22 at 03:25 +0200, Giovanni Bajo wrote:
> Besides the fact that you must have used -N, remember that you don't need all
> those merging tags anymore (forever). You can either live with a single tag
> per
> branch which you move along, or don't use tags alone and use svnmerge.py (se
13 matches
Mail list logo