[Bug fortran/40472] New: Problem with spread intrinsic

[Bug fortran/40472] New: Problem with spread intrinsic

[philippe dot marguinaud at meteo dot fr]

I use:

GNU Fortran (GCC) 4.5.0 20090617 (experimental)
Copyright (C) 2009 Free Software Foundation, Inc.

The following piece of code breaks f951 (hangs forever):

REAL, DIMENSION(720,360)          :: ZLON_MASK
ZLON_MASK(:,:)= SPREAD( (/ (JLON , JLON=1,720) /) , DIM=2, NCOPIES=360 )
END


-- 
           Summary: Problem with spread intrinsic
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: philippe dot marguinaud at meteo dot fr
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40472

[Bug fortran/40472] Problem with spread intrinsic

[dfranke at gcc dot gnu dot org]

------- Comment #1 from dfranke at gcc dot gnu dot org  2009-06-17 09:19 -------
The new simplifier, probably.

Without checking, I'd think that it doesn't hang, but would complete after a
significant amount of time. My guess: the time is spent to traverse the list to
append new elements to the constructor ...


-- 

dfranke at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dfranke at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40472

[Bug fortran/40472] Problem with spread intrinsic

[dominiq at lps dot ens dot fr]

------- Comment #2 from dominiq at lps dot ens dot fr  2009-06-17 12:57 -------
> Without checking, I'd think that it doesn't hang, but would complete after a
> significant amount of time. My guess: the time is spent to traverse the list to
> append new elements to the constructor ...

You're right! on a Core2Duo 2.1Ghz it compiles in more than 12':

[ibook-dhum] f90/bug% time gfc pr40472.f90
750.531u 1.899s 12:33.20 99.8%  0+0k 0+28io 0pf+0w

Probably a duplicate of pr34554 (see also pr19925).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40472

[Bug fortran/40472] Simplification of spread intrinsic takes a long time

[dfranke at gcc dot gnu dot org]

------- 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
the already existing splay-tree implementation (which was added for
DATA-statements). Due to real-life limitation, I didn't finish it (yet), but I
believe that's the way to go on the long run.

Philippe, to avoid the simplifier, you could replace one of the constant
expressions by a variable, e.g.

-- 8< --
REAL, DIMENSION(720,360)          :: ZLON_MASK
INTEGER :: d

d = 2
ZLON_MASK(:,:)= SPREAD( (/ (JLON , JLON=1,720) /) , DIM=d, NCOPIES=360 )
END
-- 8< --

This skips the currently inefficient process at compile-time and calls the
library implementation at run-time, as it did before.


-- 

dfranke at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
  GCC build triplet|x86_64-unknown-linux-gnu    |
   GCC host triplet|x86_64-unknown-linux-gnu    |
 GCC target triplet|x86_64-unknown-linux-gnu    |
           Keywords|                            |compile-time-hog
      Known to fail|                            |4.5.0
      Known to work|                            |4.4.1
   Last reconfirmed|0000-00-00 00:00:00         |2009-06-20 09:51:23
               date|                            |
            Summary|Problem with spread         |Simplification of spread
                   |intrinsic                   |intrinsic takes a long time


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40472

[Bug fortran/40472] Simplification of spread intrinsic takes a long time

[pault at gcc dot gnu dot org]

------- 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 simplification,
as

REAL, DIMENSION(720,360)          :: ZLON_MASK
INTEGER I
I = 720
ZLON_MASK(:,:)= SPREAD( (/ (JLON , JLON=1,I) /) , DIM=2, NCOPIES=360 )
END

shows (I suggest this as a workaround).

I have taken the PR

Paul

PS Daniel(comment #3) and I collided and so repeated the above workaround.


-- 

pault at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |pault at gcc dot gnu dot org
                   |dot org                     |
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2009-06-20 09:51:23         |2009-06-20 09:58:13
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40472

[Bug fortran/40472] Simplification of spread intrinsic takes a long time

[pault at gcc dot gnu dot org]

------- 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 expression and so, in that
respect, it is not the same as pr34554.

Cheers

Paul


-- 

pault at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |WAITING


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40472

[Bug fortran/40472] Simplification of spread intrinsic takes a long time

[dfranke at gcc dot gnu dot org]

------- 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
> respect, it is not the same as pr34554.

If used as initialization expression (as allowed by F2003), the problem is
technically the same. So, there's no easy way out :(

$> cat pr40472.f90
REAL, DIMENSION(720,360), PARAMETER :: ZLON_MASK = SPREAD( (/ (JLON ,
JLON=1,720) /) , DIM=2, NCOPIES=360 )
print *, size(ZLON_MASK)
END

$> time gfortran-svn pr40472.f90

real    11m31.051s
user    11m30.907s
sys     0m0.176s


Paul, what's your point of view on replacing the linear list by the splay-tree
('con_by_offset' in gfc_expr)?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40472

[Bug fortran/40472] Simplification of spread intrinsic takes a long time

[pault at gcc dot gnu dot org]

------- 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  <pault@gcc.gnu.org>

        PR fortran/40472
        * simplify.c (gfc_simplify_spread): Restrict the result size to
        the limit for an array constructor.

2009-06-22  Paul Thomas  <pault@gcc.gnu.org>

        PR fortran/40472
        * gfortran.dg/spread_size_limit.f90: New test.

Added:
    trunk/gcc/testsuite/gfortran.dg/spread_size_limit.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/simplify.c
    trunk/gcc/testsuite/ChangeLog


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40472

[Bug fortran/40472] Simplification of spread intrinsic takes a long time

[pault at gcc dot gnu dot org]

------- 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 here
not generated by the need to copy a 720 element array expression 360 times? 
Unless you forego the full simplification, you will always be faced with this,
surely?

Slightly puzzled

Paul


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40472

[Bug fortran/40472] Simplification of spread intrinsic takes a long time

[dominiq at lps dot ens dot fr]

------- 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 compiler error: Segmentation fault

Note that I am not sure the code is valid.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40472

[Bug fortran/40472] Simplification of spread intrinsic takes a long time

[burnus at gcc dot gnu dot org]

------- 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: __gmpz_get_si (in /usr/lib64/libgmp.so.3.5.0)
==23187==    by 0x5166F9: gfc_simplify_spread (simplify.c:5291)
==23187==    by 0x4A3BB9: gfc_check_spread (check.c:2868)
==23187==    by 0x5AE7397: ???

That's the following line:
  if (mpz_get_si (size)*ncopies > gfc_option.flag_max_array_constructor)
where size is initialized using:
  gfc_array_size (source, &size);

The problem is that SOURCE is   1   and not an array. gfc_array_size duly
returns FAILURE, but this is ignored.


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu dot
                   |                            |org
   Last reconfirmed|2009-06-20 09:58:13         |2009-06-22 11:51:34
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40472

[Bug fortran/40472] Simplification of spread intrinsic takes a long time

[dominiq at lps dot ens dot fr]

------- 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

[Bug fortran/40472] Simplification of spread intrinsic takes a long time

[burnus at gcc dot gnu dot org]

------- 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 *source, g

   /* Do not allow the array size to exceed the limit for an array
      constructor.  */
-  gfc_array_size (source, &size);
+  if (source->expr_type == EXPR_ARRAY)
+    {
+      if (gfc_array_size (source, &size) == FAILURE)
+       gfc_internal_error ("Failure getting length of a constant array.");
+    }
+  else
+    mpz_set_si (size, 1);
+
   if (mpz_get_si (size)*ncopies > gfc_option.flag_max_array_constructor)
     return NULL;


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40472

[Bug fortran/40472] Simplification of spread intrinsic takes a long time

[burnus at gcc dot gnu dot org]

------- 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

[Bug fortran/40472] Simplification of spread intrinsic takes a long time

[dominiq at lps dot ens dot fr]

------- 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

[Bug fortran/40472] Simplification of spread intrinsic takes a long time

[pault at gcc dot gnu dot org]

------- 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.

Cheers

Paul


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40472

[Bug fortran/40472] Simplification of spread intrinsic takes a long time

[burnus at gcc dot gnu dot org]

------- 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  <burnus@net-b.de>

        PR fortran/40472
        PR fortran/50520
        * simplify.c (gfc_simplify_spread): Fix the case that source=
        is a scalar.


Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/simplify.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40472

[Bug fortran/40472] Simplification of spread intrinsic takes a long time

[pault at gcc dot gnu dot org]

------- 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 PRs too?

Great :-) :-)

Paul


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40472

[Bug fortran/40472] Simplification of spread intrinsic takes a long time

[dfranke at gcc dot gnu dot org]

------- 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
----------------------------------------------------------------------------
             Status|WAITING                     |NEW
   Last reconfirmed|2009-06-22 11:51:34         |2009-12-04 22:25:27
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40472

[Bug fortran/40472] Simplification of spread intrinsic takes a long time

[dominiq at lps dot ens dot fr]

------- 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.org/bugzilla/show_bug.cgi?id=40472

[Bug fortran/40472] Simplification of spread intrinsic takes a long time

[dfranke at gcc dot gnu dot org]

------- 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 comment #1). That it "works" now is due to
Paul's patch that rejects simplifications that would result in constructors too
large to handle (by linked lists):

+  if (mpz_get_si (size)*ncopies > gfc_option.flag_max_array_constructor)
+    return NULL;

(see comment #7)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40472

[Bug fortran/40472] Simplification of spread intrinsic takes a long time

[dominiq at lps dot ens dot fr]

------- 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 *, size(ZLON_MASK), ZLON_MASK(720,360)
end
[macbook] f90/bug% time gfc pr40472_1.f90
pr40472_1.f90: In function 'MAIN__':
pr40472_1.f90:2:0: internal compiler error: in gfc_conv_array_initializer, at
fortran/trans-array.c:4189


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40472

[Bug fortran/40472] Simplification of spread intrinsic takes a long time

[dominiq at lps dot ens dot fr]

------- 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/msg00000.html

#0  fancy_abort (file=0x100987a08 "../../for_work/gcc/fortran/trans-array.c",
line=4196, function=0x1009f0560 "gfc_conv_array_initializer") at
../../for_work/gcc/diagnostic.c:727
#1  0x00000001000ac661 in gfc_conv_array_initializer (type=0x100987a08,
expr=0x1064) at ../../for_work/gcc/fortran/trans-array.c:4196
#2  0x00000001000cda9b in gfc_conv_initializer (expr=0x141814a80, ts=<value
temporarily unavailable, due to optimizations>, type=0x141df7150, array=1
'\001', pointer=<value temporarily unavailable, due to optimizations>) at
../../for_work/gcc/fortran/trans-expr.c:3757
#3  0x00000001000bc472 in gfc_get_symbol_decl (sym=0x141814740) at
../../for_work/gcc/fortran/trans-decl.c:1273
#4  0x00000001000cb60b in gfc_conv_variable (se=0x7fff5fbfe870,
expr=0x1418163b0) at ../../for_work/gcc/fortran/trans-expr.c:566
#5  0x00000001000cacbd in gfc_conv_expr_reference (se=0x7fff5fbfe870,
expr=<value temporarily unavailable, due to optimizations>) at
../../for_work/gcc/fortran/trans-expr.c:4348
#6  0x00000001000dfaa3 in gfc_trans_transfer (code=<value temporarily
unavailable, due to optimizations>) at
../../for_work/gcc/fortran/trans-io.c:2243
#7  0x00000001000a5958 in gfc_trans_code (code=0x141816760) at
../../for_work/gcc/fortran/trans.c:1250
#8  0x00000001000dd744 in build_dt (function=<value temporarily unavailable,
due to optimizations>, code=<value temporarily unavailable, due to
optimizations>) at ../../for_work/gcc/fortran/trans-io.c:1814
#9  0x00000001000a5978 in gfc_trans_code (code=0x141816970) at
../../for_work/gcc/fortran/trans.c:1222
#10 0x00000001000c1bf7 in gfc_generate_function_code (ns=<value temporarily
unavailable, due to optimizations>) at
../../for_work/gcc/fortran/trans-decl.c:4371
#11 0x00000001000691bf in gfc_parse_file () at
../../for_work/gcc/fortran/parse.c:4239
#12 0x00000001000a0ccc in gfc_be_parse_file (set_yydebug=<value temporarily
unavailable, due to optimizations>) at
../../for_work/gcc/fortran/f95-lang.c:239
#13 0x00000001006cf1fa in toplev_main (argc=2, argv=0x7fff5fbfeda0) at
../../for_work/gcc/toplev.c:1049
#14 0x00000001000019c4 in start ()


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40472

[Bug fortran/40472] Simplification of spread intrinsic takes a long time

[dfranke at gcc dot gnu dot org]

------- 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

real    0m2.130s
user    0m1.924s
sys     0m0.148s

Instead of those 11 minutes shown in comment #6.

To be fair, 4.5 requires even less time, but it builds the array on runtime,
not compile time.

$ time gfortran-4.5 -Wall pr40472.f90

real    0m0.734s
user    0m0.028s
sys     0m0.132s


Dominique, could you apply this patch and check whether you still get an ICE?

Index: simplify.c
===================================================================
--- simplify.c  (revision 158958)
+++ simplify.c  (working copy)
@@ -4926,7 +4926,6 @@ gfc_simplify_spread (gfc_expr *source, g
 {
   gfc_expr *result = 0L;
   int i, j, dim, ncopies;
-  mpz_t size;

   if ((!gfc_is_constant_expr (source)
        && !is_constant_array_expr (source))
@@ -4942,19 +4941,6 @@ gfc_simplify_spread (gfc_expr *source, g
   gfc_extract_int (ncopies_expr, &ncopies);
   ncopies = MAX (ncopies, 0);

-  /* Do not allow the array size to exceed the limit for an array
-     constructor.  */
-  if (source->expr_type == EXPR_ARRAY)
-    {
-      if (gfc_array_size (source, &size) == FAILURE)
-       gfc_internal_error ("Failure getting length of a constant array.");
-    }
-  else
-    mpz_init_set_ui (size, 1);
-
-  if (mpz_get_si (size)*ncopies > gfc_option.flag_max_array_constructor)
-    return NULL;
-
   if (source->expr_type == EXPR_CONSTANT)
     {
       gcc_assert (dim == 0);


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40472

[Bug fortran/40472] Simplification of spread intrinsic takes a long time

[dominiq at lps dot ens dot fr]

------- 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 with the patch in comment #23, the ICE with the
test in comment #21 is gone. Timing without the patch for the test in comment
#0:

[macbook] f90/bug% time gfcp pr40472.f90
0.035u 0.042s 0:00.99 7.0%      0+0k 29+4io 0pf+0w

after the patch:

[macbook] f90/bug% time gfc pr40472.f90
2.247u 0.319s 0:02.60 98.0%     0+0k 0+8io 0pf+0w
[macbook] f90/bug% time gfc pr40472_1.f90
3.371u 0.318s 0:03.75 98.1%     0+0k 0+12io 0pf+0w
[macbook] f90/bug% a.out
      259200   720.00000    


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40472

[Bug fortran/40472] Simplification of spread intrinsic takes a long time

[dfranke at gcc dot gnu dot org]

------- 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 timing correctly, that's ~4 seconds versus >10 minutes of
before? I'd call that fixed then.

Thanks for testing!


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40472

[Bug fortran/40472] Simplification of spread intrinsic takes a long time

[dominiq at lps dot ens dot fr]

------- 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? I'd call that fixed then.

If you revert the changes, don't forget to update
gcc/testsuite/gfortran.dg/spread_size_limit.f90.
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
[macbook] f90/bug% a.out 
         152   135210384
[macbook] f90/bug% time gfcp pr34554.f90
249.102u 0.129s 4:09.39 99.9%   0+0k 1+22io 0pf+0w
[macbook] f90/bug% a.out
         152   135210384

Also the timing (with/without patch) for a variant of pr19925 is:

[macbook] f90/bug% time gfc pr19925_1.f90 -fmax-array-constructor=100000
3.038u 0.175s 0:03.22 99.3%     0+0k 0+16io 0pf+0w

So, is the machinery around -fmax-array-constructor still needed?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40472

[Bug fortran/40472] Simplification of spread intrinsic takes a long time

[dfranke at gcc dot gnu dot org]

------- 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
> [macbook] f90/bug% a.out 
>          152   135210384
> [macbook] f90/bug% time gfcp pr34554.f90
> 249.102u 0.129s 4:09.39 99.9%   0+0k 1+22io 0pf+0w
> [macbook] f90/bug% a.out
>          152   135210384

The change is local to the simplifier of the SPREAD intrinsic, the testcase of
PR34554 doesn't call SPREAD, hence I'd believe this is due to system variance.
Run both versions 5-10 times and average the runtime. They should be close to
each other.

> So, is the machinery around -fmax-array-constructor still needed?

No and yes. The issue is twofold: (a) previous slowness due to usage of linked
lists and (b) out-of-memory issues if arguments are too big.

While (a) is solved now, you may hit (b) easily by increasing the size of
ZLON_MASK in the test. Multiply all the constants by 10, 100, ... eventually
you will get an ICE due to insufficient memory, similar to those other cases
you tested.

Hence, one probably should leave the check there, but increase the
max-constructor-limit by a factor of, say, 2, 4, 8, 16, ...?!


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40472

[Bug fortran/40472] Simplification of spread intrinsic takes a long time

[jvdelisle at gcc dot gnu dot org]

------- 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?id=40472

[Bug fortran/40472] Simplification of spread intrinsic takes a long time

[dfranke at gcc dot gnu dot org]

------- 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    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40472