--- Comment #32 from jvdelisle at gcc dot gnu dot org 2008-11-01 17:07
---
Finally, I hope. :)
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #31 from jvdelisle at gcc dot gnu dot org 2008-11-01 17:02
---
Subject: Bug 19925
Author: jvdelisle
Date: Sat Nov 1 17:00:49 2008
New Revision: 141519
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141519
Log:
2008-11-01 Steven G. Kargl <[EMAIL PROTECTED]>
--- Comment #30 from jvdelisle at gcc dot gnu dot org 2008-11-01 16:43
---
Subject: Bug 19925
Author: jvdelisle
Date: Sat Nov 1 16:42:31 2008
New Revision: 141518
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141518
Log:
2008-11-01 Steven G. Kargl <[EMAIL PROTECTED]>
--- Comment #29 from dominiq at lps dot ens dot fr 2008-10-11 10:31 ---
On Sat, 20 Sep 2008 08:20:29 +0200, Paul Richard Thomas wrote
(http://gcc.gnu.org/ml/gcc-patches/2008-09/msg01415.html):
> It looks good to me - I'm just out of the door for the weekend (for
> once!) - I'll attend t
--- Comment #28 from sgk at troutmask dot apl dot washington dot edu
2008-09-07 16:33 ---
Subject: Re: Implied do-loop in an initialization expression is broken
On Sun, Sep 07, 2008 at 08:25:54AM -, linuxl4 at sohu dot com wrote:
>
> somebody fix it please.
>
If it were easy to
--- Comment #27 from linuxl4 at sohu dot com 2008-09-07 08:25 ---
somebody fix it please.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19925
--- Comment #26 from sgk at troutmask dot apl dot washington dot edu
2008-02-02 16:38 ---
Subject: Re: Implied do-loop in an initialization expression is broken
On Sat, Feb 02, 2008 at 11:09:36AM -, dominiq at lps dot ens dot fr wrote:
>
> A short term solution could be to improv
--- Comment #25 from dominiq at lps dot ens dot fr 2008-02-02 11:09 ---
>From comment #24:
> ... handling the large array constructors by building the array at run time
> is obviously not fixed yet.
This can be done for
INTEGER, PARAMETER :: N=65535
INTEGER :: I(N)=(/(MOD(K,2),K=1,N)
--- Comment #24 from jvdelisle at gcc dot gnu dot org 2008-02-02 02:05
---
Reply to comment #21. I am aware of the 65535 limit. At least this minor
patch gets rid of a segfault, and handling the large array constructors by
building the array at run time is obviously not fixed yet.
-
--- Comment #23 from dominiq at lps dot ens dot fr 2008-02-01 16:58 ---
On ppc G5 1.8Ghz, I get an almost perfect quadratic behavior:
118 secs
272
4 290
6 655
65535 778
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19925
--- Comment #22 from dominiq at lps dot ens dot fr 2008-02-01 16:41 ---
For large values of n, most of the time is spent in gfc_append_constructor,
starting from 5% and up to 92%. Most of the remaining time is spent in
find_array_section, starting from 75% down to 2.5%.
Although I did n
--- Comment #21 from sgk at troutmask dot apl dot washington dot edu
2008-02-01 16:04 ---
Subject: Re: Implied do-loop in an initialization expression is broken
On Fri, Feb 01, 2008 at 03:31:49PM -, dominiq at lps dot ens dot fr wrote:
>
> With the patch in comment #18, on a Core
--- Comment #20 from dominiq at lps dot ens dot fr 2008-02-01 15:31 ---
With the patch in comment #18, on a Core2Duo 2.16Ghz I get:
5000 0.54 secs
1 1.82
2 6.74
436.5
6 206
65535 258
65536 68 <-- Error: Initialization
--- Comment #19 from burnus at gcc dot gnu dot org 2008-02-01 13:39 ---
> The ICE for the second case on comment 10 goes away. However, compile time is
> very long as N increases:
I played around (w/o your patch) with several compilers and gfortran does not
do too bad (all compilers wi
--- Comment #18 from jvdelisle at gcc dot gnu dot org 2008-02-01 04:43
---
With this patch:
@@ -1341,7 +1345,7 @@ find_array_section (gfc_expr *expr, gfc_
cons = base;
}
- while (mpz_cmp (ptr, index) > 0)
+ while (mpz_cmp (ptr, index) > 0 && cons && cons->n
--- Comment #17 from jvdelisle at gcc dot gnu dot org 2008-01-30 05:06
---
Regarding the segfault, it is similar to pr34828, but not the same place.
Apparently we do not traverse the constructors very well.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19925
--- Comment #16 from Jerry_V_DeLisle at rl dot gov 2008-01-29 15:29 ---
The segfault here is the same segfault I reported in 34828 yesterday. I have a
patch all ready for that part.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19925
--- Comment #15 from jv244 at cam dot ac dot uk 2008-01-29 06:31 ---
the comment #10 test case is still broken, and reaching its 3rd anniversary
soon. Just a back trace to the segfault:
1347 cons = cons->next;
(gdb) bt
#0 0x00422cda in find_array_section (expr=0xf7
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2008-01-08 19:04
---
This may be fixable employing gfc_trans_assignment at the right place similar
to the fix Paul used in PR34438. I have not time to chase this. Un-assigning.
--
jvdelisle at gcc dot gnu dot org changed:
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2007-11-26 06:52
---
Food for thought:
I wonder if this is best solved by creating a general purpose iterator function
that we call at run time whenever needed. A function for each Basic Type.
Seems this would be fine for initiali
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2007-11-26 06:28
---
OK, tracing this farther, the correct iterator makes it to translation at
gfc_conv_array_initializer. Here we simply have not implemented code to handle
it and we have this:
if (c->iterator)
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2007-11-26 04:50
---
I have been studying this more in some debug sessions. We actually
successfully match the iterator multiple times. However, by the time we get
through several attempted matchings, I think we get left with the l
--- Comment #10 from jv244 at cam dot ac dot uk 2007-10-29 14:59 ---
Since this is the oldest F95-only bug in gfortran, I had a look if it still
exists. I'm not quite sure it does (at in the same form).
This
INTEGER, PARAMETER :: N=10
INTEGER, PARAMETER :: I(N)=(/(MOD(K,2),K=1,N)/)
--- Comment #9 from tobi at gcc dot gnu dot org 2007-10-06 14:09 ---
There's no related bug field, but it's worth mentioning that PR20923 and this
should probably be attacked at the same time.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19925
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2007-05-09 04:02
---
Apparently the magic limit here is 65535, not 10 as stated previously.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19925
--- Comment #7 from bdtaylo1 at uiuc dot edu 2007-01-02 21:47 ---
(In reply to comment #6)
> (The _i_initialized variable is not needed in a main program, but it is in a
> procedure.) This far it isn't a huge problem, but when 'i' is a PARAMETER it
> gets more complicated. PARAMETERs are
--- Comment #6 from eedelman at gcc dot gnu dot org 2006-01-10 00:03
---
(In reply to comment #5)
> The limit was rose but we should be able to do better.
Indeed. But the problem is not trivial. For a case like above, where the
array is a variable, we can translate it to
(program|fu
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-01-09 22:33 ---
Here is a testcase which fails currently because of this bug:
program stuff
integer :: i_do
integer :: i(11) = (/ (i_do, i_do=1,11) /)
write (*,*) i
end program stuff
-
The limit was
--- Comment #4 from pinskia at gcc dot gnu dot org 2005-11-04 01:19 ---
Hmm, I might take a look at this bug as I found it independently while
compiling some other fortran code.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19925
--- Additional Comments From erik dot edelmann at iki dot fi 2005-07-28
11:50 ---
This bug has been briefly discussed on the mailing list:
http://gcc.gnu.org/ml/fortran/2005-06/msg00485.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19925
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-05-14
20:58 ---
*** Bug 20925 has been marked as a duplicate of this bug. ***
--
What|Removed |Added
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-12
16:40 ---
Confirmed.
--
What|Removed |Added
Status|UNCONFIRMED |NEW
E
32 matches
Mail list logo
