[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