--- Comment #13 from dominiq at lps dot ens dot fr 2010-05-15 16:43 ---
AFAICT revision 159366 (fix of pr35779) has the side effect of fixing the ICE
reported in comment #0 without patching gcc/fortran/simplify.c as in comment
#0.
--
--- Comment #14 from dominiq at lps dot ens dot fr 2010-05-15 21:21 ---
(In reply to comment #13)
AFAICT revision 159366 (fix of pr35779) has the side effect of fixing the ICE
reported in comment #0 without patching gcc/fortran/simplify.c as in comment
comment #0.
No longer true at
--- Comment #9 from dominiq at lps dot ens dot fr 2010-05-06 08:51 ---
(In reply to comment #8)
For increasing N it (a) takes longer and longer - probably quadratic time -
N=100: 0.716u 0.031s 0:00.75
N=200: 5.297u 0.071s 0:05.37
N=400: 40.334u 0.125s 0:40.76
It looks like cubic
--- Comment #10 from dfranke at gcc dot gnu dot org 2010-05-06 10:00
---
(In reply to comment #9)
It looks like cubic time in N.
http://en.wikipedia.org/wiki/Matrix_multiplication#Algorithms_for_efficient_matrix_multiplication:
The running time of square matrix multiplication, if
--- Comment #11 from dominiq at lps dot ens dot fr 2010-05-06 10:27 ---
... O(mnp) ...
With m=n=N and p=1, this gives O(N^2), hence my expectation for MATMUL in
comment #9!-)
Question: what is the origin of the O(N^3) time?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43996
--- Comment #12 from dfranke at gcc dot gnu dot org 2010-05-06 10:32
---
(In reply to comment #11)
Question: what is the origin of the O(N^3) time?
Building of and operating on a tree of 10.000, 40.000, 90.000, ... elements
respectively? Probably cheaper then linked lists, but not
--- Comment #1 from dfranke at gcc dot gnu dot org 2010-05-05 21:22 ---
And I checked again. There's nothing on i686-pc-linux-gnu. Not even with
valgrind,
Btw, Dominique, since valgrind-3.5.0, it is available for Mac as well [1].
Would you mind to get valgrind and run f951 through it?
--- Comment #2 from dominiq at lps dot ens dot fr 2010-05-05 21:30 ---
And I checked again. There's nothing on i686-pc-linux-gnu. Not even with
valgrind,
Could someone try on x86_64-*-linux-*?
Btw, Dominique, since valgrind-3.5.0, it is available for Mac as well [1].
Would you
--- Comment #3 from dominiq at lps dot ens dot fr 2010-05-05 21:48 ---
With i686-apple-darwin9 at revision 156693, valgrind gives:
MAIN__
pr40472_1.f90:2:0: internal compiler error: in gfc_conv_array_initializer, at
fortran/trans-array.c:4189
Please submit a full bug report,
with
--- Comment #4 from dfranke at gcc dot gnu dot org 2010-05-05 21:59 ---
For ICEs, the interesting messages are before the ICE itself; most often
something like invalid read, invalid write or used of uninitialized
value.
The loss records are (mainly) due to the ICE which doesn't allow
--- Comment #5 from dominiq at lps dot ens dot fr 2010-05-05 22:02 ---
What is before MAIN__ is:
[ibook-dhum] f90/bug% valgrind --leak-check=full --show-reachable=yes
/opt/gcc/gcc4.5w/libexec/gcc/i686-apple-darwin9/4.5.0/f951 pr40472_1.f90
==187== Memcheck, a memory error detector.
--- Comment #6 from dfranke at gcc dot gnu dot org 2010-05-05 22:18 ---
Ignore my previous claims. I now realized that you used a somewhat different
testcase, not the one from PR40472 - my bad :(
$ time gfortran-svn pr43996.f90
pr43996.f90: In function 'MAIN__':
pr43996.f90:4:0:
--- Comment #7 from dominiq at lps dot ens dot fr 2010-05-05 22:28 ---
The patch has the same effect as the -fmax-array-constructor=HUGE.
It makes also the compilation slightly faster:
[macbook] f90/bug% time gfcp -fmax-array-constructor=259200 pr40472_1.f90
4.524u 0.547s 0:05.22
--- Comment #8 from dfranke at gcc dot gnu dot org 2010-05-05 23:08 ---
It's late, but a conjecture ...
trans-array.c (gfc_conv_array_initializer):
/* Create an array constructor from an initialization expression.
We assume the frontend already did any expansions and conversions.
14 matches
Mail list logo
