[Bug fortran/43996] New: ICE in simplification of spread intrinsic

[Bug fortran/43996] New: ICE in simplification of spread intrinsic

[dominiq at lps dot ens dot fr]

The following test extracted from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40472#c21 gives an ICE with vanilla
trunk at revision 159082:

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% gfcp 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:4222

The backtrace is

Breakpoint 1, fancy_abort (file=0x100992a40
"../../p_work/gcc/fortran/trans-array.c", line=4222, function=0x1009fc620
"gfc_conv_array_initializer") at ../../p_work/gcc/diagnostic.c:810
810     {
(gdb) bt
#0  fancy_abort (file=0x100992a40 "../../p_work/gcc/fortran/trans-array.c",
line=4222, function=0x1009fc620 "gfc_conv_array_initializer") at
../../p_work/gcc/diagnostic.c:810
#1  0x00000001000b1f21 in gfc_conv_array_initializer (type=0x141e13738,
expr=0x141814bc0) at ../../p_work/gcc/fortran/trans-array.c:4222
#2  0x00000001000d3ecb in gfc_conv_initializer (expr=0x141814bc0, ts=<value
temporarily unavailable, due to optimizations>, type=0x141e13738, array=<value
temporarily unavailable, due to optimizations>, pointer=<value temporarily
unavailable, due to optimizations>) at
../../p_work/gcc/fortran/trans-expr.c:3886
#3  0x00000001000c20f2 in gfc_get_symbol_decl (sym=0x141814880) at
../../p_work/gcc/fortran/trans-decl.c:1295
#4  0x00000001000d179b in gfc_conv_variable (se=0x7fff5fbfd480,
expr=0x14181eb40) at ../../p_work/gcc/fortran/trans-expr.c:569
#5  0x00000001000d0e3d in gfc_conv_expr_reference (se=0x7fff5fbfd480,
expr=<value temporarily unavailable, due to optimizations>) at
../../p_work/gcc/fortran/trans-expr.c:4554
#6  0x00000001000e6114 in gfc_trans_transfer (code=0x14181ef30) at
../../p_work/gcc/fortran/trans-io.c:2246
#7  0x00000001000aac88 in trans_code (code=0x14181ef30, cond=0x1417f5118) at
../../p_work/gcc/fortran/trans.c:1261
#8  0x00000001000e3d69 in build_dt (function=0x141e11200, code=0x14181f320) at
../../p_work/gcc/fortran/trans-io.c:1817
#9  0x00000001000aaca8 in trans_code (code=0x14181f320, cond=0x0) at
../../p_work/gcc/fortran/trans.c:1233
#10 0x00000001000c7a4f in gfc_generate_function_code (ns=<value temporarily
unavailable, due to optimizations>) at
../../p_work/gcc/fortran/trans-decl.c:4422
#11 0x000000010006ba4f in gfc_parse_file () at
../../p_work/gcc/fortran/parse.c:4317
#12 0x00000001000a611c in gfc_be_parse_file (set_yydebug=<value temporarily
unavailable, due to optimizations>) at ../../p_work/gcc/fortran/f95-lang.c:239
#13 0x00000001006d959c in toplev_main (argc=2, argv=0x7fff5fbfd9f0) at
../../p_work/gcc/toplev.c:1053
#14 0x00000001000015c4 in start ()

If the following patch is applied:

diff -up ../_clean/gcc/fortran/simplify.c gcc/fortran/simplify.c
--- ../_clean/gcc/fortran/simplify.c    2010-04-28 22:47:13.000000000 +0200
+++ gcc/fortran/simplify.c      2010-05-05 20:01:15.000000000 +0200
@@ -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);

The ICE goes away:

[macbook] f90/bug% gfc pr40472_1.f90
[macbook] f90/bug% a.out 
      259200   720.00000


-- 
           Summary: ICE in simplification of spread intrinsic
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: dominiq at lps dot ens dot fr


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

[Bug fortran/43996] ICE in simplification of spread intrinsic

[dfranke at gcc dot gnu dot org]

------- 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? It may give a hint?!

[1] http://valgrind.org/downloads/current.html


-- 

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

[Bug fortran/43996] ICE in simplification of spread intrinsic

[dominiq at lps dot ens dot fr]

------- 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 mind to get valgrind and run f951 through it? It may give a hint?!

Unfortunately valgrind has not been ported yet to darwin10!-(

Note I get an ICE on powerpc-apple-darwin9 also.


-- 


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

[Bug fortran/43996] ICE in simplification of spread intrinsic

[dominiq at lps dot ens dot fr]

------- 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 preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
==187== 
==187== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==187== malloc/free: in use at exit: 436,741 bytes in 4,777 blocks.
==187== malloc/free: 28,742 allocs, 23,965 frees, 1,807,223 bytes allocated.
==187== For counts of detected errors, rerun with: -v
==187== searching for pointers to 4,777 not-freed blocks.
==187== checked 1,082,195,616 bytes.
==187== 
==187== 4 bytes in 1 blocks are still reachable in loss record 1 of 20
==187==    at 0x40EC0516: malloc (vg_replace_malloc.c:193)
==187==    by 0x41666111: strdup (in /usr/lib/libSystem.B.dylib)
==187==    by 0xA42507: libintl_textdomain (textdomain.c:111)
==187== 
==187== 
==187== 16 bytes in 4 blocks are indirectly lost in loss record 2 of 20
==187==    at 0x40EC0516: malloc (vg_replace_malloc.c:193)
==187==    by 0x415A87CB: __gmp_default_allocate (in
/sw/lib/libgmp.3.5.0.dylib)
==187== 
==187== 
==187== 32 bytes in 4 blocks are still reachable in loss record 3 of 20
==187==    at 0x40EC22B8: realloc (vg_replace_malloc.c:472)
==187==    by 0x415A8823: __gmp_default_reallocate (in
/sw/lib/libgmp.3.5.0.dylib)
==187==    by 0x58CD: gfc_convert_integer (fortran/arith.c:1930)
==187==    by 0x70DE9: gfc_match_literal_constant (fortran/primary.c:1338)
==187== 
==187== 
==187== 32 bytes in 4 blocks are definitely lost in loss record 4 of 20
==187==    at 0x40EC22B8: realloc (vg_replace_malloc.c:472)
==187==    by 0x415A8823: __gmp_default_reallocate (in
/sw/lib/libgmp.3.5.0.dylib)
==187== 
==187== 
==187== 43 bytes in 2 blocks are still reachable in loss record 5 of 20
==187==    at 0x40EC0516: malloc (vg_replace_malloc.c:193)
==187==    by 0xA400BF: set_binding_values (bindtextdom.c:233)
==187== 
==187== 
==187== 60 bytes in 1 blocks are still reachable in loss record 6 of 20
==187==    at 0x40EC0516: malloc (vg_replace_malloc.c:193)
==187==    by 0x41643C49: get_or_create_key_element (in
/usr/lib/libSystem.B.dylib)
==187==    by 0x41643B7B: _keymgr_get_and_lock_processwide_ptr_2 (in
/usr/lib/libSystem.B.dylib)
==187==    by 0x416437C1: dwarf2_unwind_dyld_add_image_hook (in
/usr/lib/libSystem.B.dylib)
==187==    by 0x8FE03D61: dyld::registerAddCallback(void (*)(mach_header
const*, long)) (in /usr/lib/dyld)
==187==    by 0x41642B3A: _dyld_register_func_for_add_image (in
/usr/lib/libSystem.B.dylib)
==187==    by 0x4163BCB5: __keymgr_initializer (in /usr/lib/libSystem.B.dylib)
==187==    by 0x4163B0C0: libSystem_initializer (in /usr/lib/libSystem.B.dylib)
==187==    by 0x8FE12F35:
ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) (in
/usr/lib/dyld)
==187==    by 0x8FE0E7E2:
ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned
int) (in /usr/lib/dyld)
==187==    by 0x8FE0E774:
ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned
int) (in /usr/lib/dyld)
==187==    by 0x8FE0E774:
ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned
int) (in /usr/lib/dyld)
==187== 
==187== 
==187== 64 bytes in 1 blocks are still reachable in loss record 7 of 20
==187==    at 0x40EC0516: malloc (vg_replace_malloc.c:193)
==187==    by 0x41640D76: localeconv_l (in /usr/lib/libSystem.B.dylib)
==187==    by 0x4163C334: __vfprintf (in /usr/lib/libSystem.B.dylib)
==187==    by 0x41663C25: sprintf (in /usr/lib/libSystem.B.dylib)
==187==    by 0x6956A8: register_one_dump_file (passes.c:391)
==187== 
==187== 
==187== 64 (48 direct, 16 indirect) bytes in 2 blocks are definitely lost in
loss record 8 of 20
==187==    at 0x40EC0516: malloc (vg_replace_malloc.c:193)
==187==    by 0xA52699: xmalloc (xmalloc.c:147)
==187== 
==187== 
==187== 136 bytes in 10 blocks are still reachable in loss record 9 of 20
==187==    at 0x40EC22B8: realloc (vg_replace_malloc.c:472)
==187==    by 0x415A8823: __gmp_default_reallocate (in
/sw/lib/libgmp.3.5.0.dylib)
==187==    by 0x415BB184: __gmpz_pow_ui (in /sw/lib/libgmp.3.5.0.dylib)
==187== 
==187== 
==187== 176 bytes in 14 blocks are possibly lost in loss record 10 of 20
==187==    at 0x40EC0516: malloc (vg_replace_malloc.c:193)
==187==    by 0x415A87CB: __gmp_default_allocate (in
/sw/lib/libgmp.3.5.0.dylib)
==187== 
==187== 
==187== 520 bytes in 1 blocks are still reachable in loss record 11 of 20
==187==    at 0x40EC0516: malloc (vg_replace_malloc.c:193)
==187==    by 0x41643167: atexit_register (in /usr/lib/libSystem.B.dylib)
==187==    by 0x416430EC: __cxa_atexit (in /usr/lib/libSystem.B.dylib)
==187==    by 0x414D16F5: __static_initialization_and_destruction_0(int, int)
(in /sw/lib/libppl.7.dylib)
==187==    by 0x8FE12F35:
ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) (in
/usr/lib/dyld)
==187==    by 0x8FE0E7E2:
ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned
int) (in /usr/lib/dyld)
==187==    by 0x8FE0E774:
ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned
int) (in /usr/lib/dyld)
==187==    by 0x8FE0E774:
ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned
int) (in /usr/lib/dyld)
==187==    by 0x8FE0E774:
ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned
int) (in /usr/lib/dyld)
==187==    by 0x8FE0E8C8: ImageLoader::runInitializers(ImageLoader::LinkContext
const&) (in /usr/lib/dyld)
==187==    by 0x8FE04101: dyld::initializeMainExecutable() (in /usr/lib/dyld)
==187==    by 0x8FE07BCE: dyld::_main(mach_header const*, unsigned long, int,
char const**, char const**, char const**) (in /usr/lib/dyld)
==187== 
==187== 
==187== 680 bytes in 17 blocks are still reachable in loss record 12 of 20
==187==    at 0x40EC20F7: calloc (vg_replace_malloc.c:414)
==187==    by 0x41643799: dwarf2_unwind_dyld_add_image_hook (in
/usr/lib/libSystem.B.dylib)
==187==    by 0x8FE03D61: dyld::registerAddCallback(void (*)(mach_header
const*, long)) (in /usr/lib/dyld)
==187==    by 0x41642B3A: _dyld_register_func_for_add_image (in
/usr/lib/libSystem.B.dylib)
==187==    by 0x4163BCB5: __keymgr_initializer (in /usr/lib/libSystem.B.dylib)
==187==    by 0x4163B0C0: libSystem_initializer (in /usr/lib/libSystem.B.dylib)
==187==    by 0x8FE12F35:
ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) (in
/usr/lib/dyld)
==187==    by 0x8FE0E7E2:
ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned
int) (in /usr/lib/dyld)
==187==    by 0x8FE0E774:
ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned
int) (in /usr/lib/dyld)
==187==    by 0x8FE0E774:
ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned
int) (in /usr/lib/dyld)
==187==    by 0x8FE0E8C8: ImageLoader::runInitializers(ImageLoader::LinkContext
const&) (in /usr/lib/dyld)
==187==    by 0x8FE040E8: dyld::initializeMainExecutable() (in /usr/lib/dyld)
==187== 
==187== 
==187== 3,120 bytes in 6 blocks are still reachable in loss record 13 of 20
==187==    at 0x40EC0516: malloc (vg_replace_malloc.c:193)
==187==    by 0x41643167: atexit_register (in /usr/lib/libSystem.B.dylib)
==187==    by 0x416430EC: __cxa_atexit (in /usr/lib/libSystem.B.dylib)
==187==    by 0x414D0955: __static_initialization_and_destruction_0(int, int)
(in /sw/lib/libppl.7.dylib)
==187==    by 0x8FE12F35:
ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const&) (in
/usr/lib/dyld)
==187==    by 0x8FE0E7E2:
ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned
int) (in /usr/lib/dyld)
==187==    by 0x8FE0E774:
ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned
int) (in /usr/lib/dyld)
==187==    by 0x8FE0E774:
ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned
int) (in /usr/lib/dyld)
==187==    by 0x8FE0E774:
ImageLoader::recursiveInitialization(ImageLoader::LinkContext const&, unsigned
int) (in /usr/lib/dyld)
==187==    by 0x8FE0E8C8: ImageLoader::runInitializers(ImageLoader::LinkContext
const&) (in /usr/lib/dyld)
==187==    by 0x8FE04101: dyld::initializeMainExecutable() (in /usr/lib/dyld)
==187==    by 0x8FE07BCE: dyld::_main(mach_header const*, unsigned long, int,
char const**, char const**, char const**) (in /usr/lib/dyld)
==187== 
==187== 
==187== 4,428 bytes in 5 blocks are still reachable in loss record 14 of 20
==187==    at 0x40EC0516: malloc (vg_replace_malloc.c:193)
==187==    by 0xA52747: xrealloc (xmalloc.c:177)
==187== 
==187== 
==187== 8,692 bytes in 2,173 blocks are still reachable in loss record 15 of 20
==187==    at 0x40EC0516: malloc (vg_replace_malloc.c:193)
==187==    by 0x415A87CB: __gmp_default_allocate (in
/sw/lib/libgmp.3.5.0.dylib)
==187== 
==187== 
==187== 9,080 bytes in 4 blocks are still reachable in loss record 16 of 20
==187==    at 0x40EC22B8: realloc (vg_replace_malloc.c:472)
==187==    by 0xA52735: xrealloc (xmalloc.c:179)
==187== 
==187== 
==187== 16,032 bytes in 2 blocks are possibly lost in loss record 17 of 20
==187==    at 0x40EC0516: malloc (vg_replace_malloc.c:193)
==187==    by 0xA52699: xmalloc (xmalloc.c:147)
==187==    by 0x76D907: toplev_main (toplev.c:1806)
==187== 
==187== 
==187== 35,556 bytes in 7 blocks are still reachable in loss record 18 of 20
==187==    at 0x40EC20F7: calloc (vg_replace_malloc.c:414)
==187==    by 0xA526D6: xcalloc (xmalloc.c:162)
==187==    by 0x76D907: toplev_main (toplev.c:1806)
==187== 
==187== 
==187== 57,429 bytes in 764 blocks are still reachable in loss record 19 of 20
==187==    at 0x40EC0516: malloc (vg_replace_malloc.c:193)
==187==    by 0xA52699: xmalloc (xmalloc.c:147)
==187== 
==187== 
==187== 300,593 bytes in 1,755 blocks are still reachable in loss record 20 of
20
==187==    at 0x40EC20F7: calloc (vg_replace_malloc.c:414)
==187==    by 0xA526D6: xcalloc (xmalloc.c:162)
==187== 
==187== LEAK SUMMARY:
==187==    definitely lost: 80 bytes in 6 blocks.
==187==    indirectly lost: 16 bytes in 4 blocks.
==187==      possibly lost: 16,208 bytes in 16 blocks.
==187==    still reachable: 420,437 bytes in 4,751 blocks.
==187==         suppressed: 0 bytes in 0 blocks.


-- 


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

[Bug fortran/43996] ICE in simplification of spread intrinsic

[dfranke at gcc dot gnu dot org]

------- 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 the
application to properly clean up after itself.


-- 


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

[Bug fortran/43996] ICE in simplification of spread intrinsic

[dominiq at lps dot ens dot fr]

------- 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.
==187== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==187== Using LibVEX rev exported, a library for dynamic binary translation.
==187== Copyright (C) 2004-2009, and GNU GPL'd, by OpenWorks LLP.
==187== Using valgrind-3.5.0.SVN, a dynamic binary instrumentation framework.
==187== Copyright (C) 2000-2009, and GNU GPL'd, by Julian Seward et al.
==187== For more details, rerun with: -v
==187== 
==187== Warning: set address range perms: large range [0xc20000, 0x40c7e000)
(defined)


-- 


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

[Bug fortran/43996] ICE in simplification of spread intrinsic

[dfranke at gcc dot gnu dot org]

------- 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: internal compiler error: in gfc_conv_array_initializer, at
fortran/trans-array.c:4222

That's a gcc_unreachable() ...


$ time gfortran-svn pr43996.f90 -fmax-array-constructor=1000000 && ./a.out
real    0m4.093s
user    0m3.744s
sys     0m0.228s
      259200   720.00000 

The patch has the same effect as the -fmax-array-constructor=HUGE.


-- 

dfranke at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2010-05-05 22:18:03
               date|                            |


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

[Bug fortran/43996] ICE in simplification of spread intrinsic

[dominiq at lps dot ens dot fr]

------- 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 96.9%     0+0k 10+12io 0pf+0w
[macbook] f90/bug% a.out 
      259200   720.00000    
[macbook] f90/bug% time gfc pr40472_1.f90
3.352u 0.313s 0:04.41 82.9%     0+0k 6+3io 0pf+0w
[macbook] f90/bug% a.out
      259200   720.00000    


-- 


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

[Bug fortran/43996] ICE in simplification of spread intrinsic

[dfranke at gcc dot gnu dot org]

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

Initialization expressions are required to be fully simplify-able at compile
time, otherwise an error is reported. Here, we have an allowed init expression
that has not been simplified but comes as a function call to be executed at
runtime. Hence, to fix this, one may need to handle EXPR_FUNCTION - or fully
expand the constructor.

Another candidate for this issue is MATMUL:
  INTEGER            :: i
  INTEGER, PARAMETER :: N = 100, M = 1

  INTEGER, PARAMETER :: A(N, M) = RESHAPE((/ (i, i = 1, N) /), (/ N, M /))
  INTEGER, PARAMETER :: B(M, N) = RESHAPE((/ (i, i = 1, N) /), (/ M, N /))
  INTEGER, PARAMETER :: C(N, N) = MATMUL(A, B)

  PRINT *, SIZE(C), C(N/2, N/2)
END

For increasing N it (a) takes longer and longer - probably quadratic time - and
(b) eventually all memory will be used which leads to a crash. Adding a
max-constructor-size check to MATMUL will again bring us here. Test by
unconditionally returning NULL in MATMUL:

$ time gfortran-svn matmul.f03 && ./a.out 
matmul.f03: In function 'MAIN__':
matmul.f03:1:0: internal compiler error: in gfc_conv_array_initializer, at
fortran/trans-array.c:4222


-- 

dfranke at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-valid-code
      Known to fail|                            |4.6.0


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

[Bug fortran/43996] ICE in simplification of spread intrinsic

[dominiq at lps dot ens dot fr]

------- 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 time in N. For M=1, I would expect that MATMUL is quadratic
in N (although I did not check). Does this mean that building each element is
O(N)?

> and (b) eventually all memory will be used which leads to a crash. 

As in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40472#c27, I think there is a
confusion between front-end and middle-end problems:

When the initialization expressions appear in PARAMETERS, they have to be
computed by the front-end (?) which may lead to a very long compilation time,
but I have never seen any memory problems (with Gbs of RAM), i.e., I did not
have the patience to test large enough expressions.

This is different to what happens for instance in pr32489 where the expression
passed to the middle-end is so complicated that the middle-end is confused and
exhausts the available memory.

> Adding a max-constructor-size check to MATMUL will again bring us here. Test by
> unconditionally returning NULL in MATMUL: ...

I cannot reproduce that, am I correct to understand that you used some patched
gfortran?

Apparently, all the intrinsics should be audited for this kind of problem.


-- 


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

[Bug fortran/43996] ICE in simplification of spread intrinsic

[dfranke at gcc dot gnu dot org]

------- 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 carried out naively, is
O(n^3). The running time for multiplying rectangular matrices (one m x p-matrix
with one p x n-matrix) is O(mnp)"

Better algorithms than the one implemented exist.


> > unconditionally returning NULL in MATMUL: ...
> 
> I cannot reproduce that, am I correct to understand that you used some patched
> gfortran?

Index: simplify.c
===================================================================
--- simplify.c  (revision 159089)
+++ simplify.c  (working copy)
@@ -3294,6 +3294,8 @@ gfc_simplify_matmul (gfc_expr *matrix_a,
   int row, result_rows, col, result_columns;
   int stride_a, offset_a, stride_b, offset_b;

+  return NULL;
+
   if (!is_constant_array_expr (matrix_a)
       || !is_constant_array_expr (matrix_b))
     return NULL;


> Apparently, all the intrinsics should be audited for this kind of problem.

Transformational intrinsics that return an arrays, to begin with.


-- 


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

[Bug fortran/43996] ICE in simplification of spread intrinsic

[dominiq at lps dot ens dot fr]

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

[Bug fortran/43996] ICE in simplification of spread intrinsic

[dfranke at gcc dot gnu dot org]

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


-- 


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

[Bug fortran/43996] ICE in simplification of spread intrinsic

[dominiq at lps dot ens dot fr]

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


-- 


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

[Bug fortran/43996] ICE in simplification of spread intrinsic

[dominiq at lps dot ens dot fr]

------- 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 revision 159435!-(


-- 


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

[Bug fortran/43996] ICE in gfc_conv_array_initializer due to incomplete simplification of init expressions

[dfranke at gcc dot gnu dot org]

------- Comment #15 from dfranke at gcc dot gnu dot org  2010-05-23 15:37 -------
Adjusted summary to better describe the problem.


-- 

dfranke at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|ICE in simplification of    |ICE in
                   |spread intrinsic            |gfc_conv_array_initializer
                   |                            |due to incomplete
                   |                            |simplification of init
                   |                            |expressions


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