--- Comment #29 from dfranke at gcc dot gnu dot org 2010-05-01 14:52
---
(In reply to comment #28)
> Yes, please leave the limit in and allow users to change the max.
Ok. Closing this PR as very thoroughly FIXED then :)
--
dfranke at gcc dot gnu dot org changed:
What
--- Comment #28 from jvdelisle at gcc dot gnu dot org 2010-05-01 14:37
---
Yes, please leave the limit in and allow users to change the max. This is a
safety net and also communicates to users they have to be careful what they are
doing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?
--- Comment #27 from dfranke at gcc dot gnu dot org 2010-05-01 13:08
---
(In reply to comment #26)
> Also I see a small slow down for the test in pr34554 (gfc is patched, gfcp
> not):
>
> [macbook] f90/bug% time gfc pr34554.f90
> 259.917u 0.168s 4:20.44 99.8% 0+0k 0+29io 0pf+0w
> [mac
--- Comment #26 from dominiq at lps dot ens dot fr 2010-05-01 12:52 ---
> The patch in #23 actually reverts the previous changes :)
I blindly applied the patch without looking at the previous changes!)
> If I read your timing correctly, that's ~4 seconds versus >10 minutes of
> before?
--- Comment #25 from dfranke at gcc dot gnu dot org 2010-05-01 12:27
---
(In reply to comment #24)
> Without undoing the changes but with the patch in comment #23, the
> ICE with the test in comment #21 is gone.
The patch in #23 actually reverts the previous changes :)
If I read your
--- Comment #24 from dominiq at lps dot ens dot fr 2010-05-01 12:14 ---
> Undoing the changes of comments #7, #12 and #16, I now (with splay-tree
> constructors get):
> ...
> Dominique, could you apply this patch and check whether you still get an ICE?
Without undoing the changes but wi
--- Comment #23 from dfranke at gcc dot gnu dot org 2010-05-01 11:15
---
Undoing the changes of comments #7, #12 and #16, I now (with splay-tree
constructors get):
$ time gfortran-svn -Wall pr40472.f90
real0m2.130s
user0m1.924s
sys 0m0.148s
Instead of those 11 minutes sho
--- Comment #22 from dominiq at lps dot ens dot fr 2010-01-02 11:49 ---
Backtrace of the ICE in comment #21 with the patch in
http://gcc.gnu.org/ml/fortran/2010-01/msg0.html
#0 fancy_abort (file=0x100987a08 "../../for_work/gcc/fortran/trans-array.c",
line=4196, function=0x1009f0560
--- Comment #21 from dominiq at lps dot ens dot fr 2009-12-04 22:47 ---
> Pretty sure.
The following ICE is probably a signature:
[macbook] f90/bug% cat > pr40472_1.f90
REAL, DIMENSION(720,360), PARAMETER :: ZLON_MASK = SPREAD( (/ (JLON ,
JLON=1,720) /) , DIM=2, NCOPIES=360 )
print *,
--- Comment #20 from dfranke at gcc dot gnu dot org 2009-12-04 22:40
---
(In reply to comment #19)
> > Changing to NEW as it (unfortunately) still is.
>
> Are you sure?
Pretty sure. I haven't checked the sources in a while, but I doubt that anyone
got rid of the linear lists (see comm
--- Comment #19 from dominiq at lps dot ens dot fr 2009-12-04 22:35 ---
> Changing to NEW as it (unfortunately) still is.
Are you sure? on a macbook Core2Duo 2.53Ghz I get:
[macbook] f90/bug% time gfc pr40472.f90
0.024u 0.021s 0:00.05 80.0% 0+0k 0+8io 0pf+0w
--
http://gcc.gnu.
--- Comment #18 from dfranke at gcc dot gnu dot org 2009-12-04 22:25
---
What is this one waiting for? Changing to NEW as it (unfortunately) still is.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #17 from pault at gcc dot gnu dot org 2009-07-10 11:37 ---
(In reply to comment #16)
> PR fortran/40472
> PR fortran/50520
> * simplify.c (gfc_simplify_spread): Fix the case that source=
> is a scalar.
Hey, Tobias are you fixing future P
--- Comment #16 from burnus at gcc dot gnu dot org 2009-06-22 20:24 ---
Subject: Bug 40472
Author: burnus
Date: Mon Jun 22 20:24:18 2009
New Revision: 148814
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148814
Log:
2009-06-22 Tobias Burnus
PR fortran/40472
--- Comment #15 from pault at gcc dot gnu dot org 2009-06-22 20:02 ---
(In reply to comment #13)
> Too quick. That should be: mpz_init_set_si or mpz_init_set_ui; the _init_ was
> missing.
>
Dang it! OK that's right. Can you commit that correction - I cannot do so
until Thursday.
Ch
--- Comment #14 from dominiq at lps dot ens dot fr 2009-06-22 19:50 ---
The patch in comments #12 and #13 fixes the problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40472
--- Comment #13 from burnus at gcc dot gnu dot org 2009-06-22 14:32 ---
> + else
> +mpz_set_si (size, 1);
Too quick. That should be: mpz_init_set_si or mpz_init_set_ui; the _init_ was
missing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40472
--- Comment #12 from burnus at gcc dot gnu dot org 2009-06-22 14:21 ---
Patch
Index: simplify.c
===
--- simplify.c (revision 148777)
+++ simplify.c (working copy)
@@ -5117,7 +5117,14 @@ gfc_simplify_spread (gfc_expr *sour
--- Comment #11 from dominiq at lps dot ens dot fr 2009-06-22 12:56 ---
See also http://gcc.gnu.org/ml/gcc-testresults/2009-06/msg01767.html for a lot
of related failures.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40472
--- Comment #10 from burnus at gcc dot gnu dot org 2009-06-22 11:51 ---
(In reply to comment #9)
> At revision 148777 (but not at r148732) [...] Segmentation fault
Does not segfault here, but I get with valgrind:
==23187== Use of uninitialised value of size 8
==23187==at 0x52A29C8:
--- Comment #9 from dominiq at lps dot ens dot fr 2009-06-22 09:04 ---
At revision 148777 (but not at r148732), the following code:
print *, spread(1,dim=1,ncopies=3)
print *, spread(1,dim=1,ncopies=0)
end
gives
[ibook-dhum] f90/bug% gfc zero_spread_red.f90
f951: internal compil
--- Comment #8 from pault at gcc dot gnu dot org 2009-06-22 04:48 ---
(In reply to comment #6)
> Paul, what's your point of view on replacing the linear list by the splay-tree
> ('con_by_offset' in gfc_expr)?
>
I do not know enough about splay trees to comment; however, is the problem
--- Comment #7 from pault at gcc dot gnu dot org 2009-06-22 04:39 ---
Subject: Bug 40472
Author: pault
Date: Mon Jun 22 04:39:40 2009
New Revision: 148775
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148775
Log:
2009-06-22 Paul Thomas
PR fortran/40472
* sim
--- Comment #6 from dfranke at gcc dot gnu dot org 2009-06-20 12:01 ---
(In reply to comment #4)
> > Essentially yes, but the compile-time simplifier for spread (and others)
> > was introduced only recently.
>
> As I say above, this is not an initialization expression and so, in that
> r
--- Comment #5 from pault at gcc dot gnu dot org 2009-06-20 10:00 ---
(In reply to comment #3)
> > Probably a duplicate of pr34554
>
> Essentially yes, but the compile-time simplifier for spread (and others) was
> introduced only recently.
As I say above, this is not an initialization
--- Comment #4 from pault at gcc dot gnu dot org 2009-06-20 09:58 ---
This one must be fixed. When the upper limit on array simplification was
removed, it was with initialization expressions in mind. In this case, the
assignment compiles and runs at a sensible pace if there is no simpl
--- Comment #3 from dfranke at gcc dot gnu dot org 2009-06-20 09:51 ---
> Probably a duplicate of pr34554
Essentially yes, but the compile-time simplifier for spread (and others) was
introduced only recently.
A while ago, I started an attempt to replace the linear constructor list with
27 matches
Mail list logo
