--- Comment #7 from burnus at gcc dot gnu dot org 2007-06-25 08:02 ---
*** Bug 32489 has been marked as a duplicate of this bug. ***
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20923
--- Comment #6 from burnus at gcc dot gnu dot org 2007-03-21 21:56 ---
*** Bug 31301 has been marked as a duplicate of this bug. ***
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2006-09-10 05:05
---
This bug is related to slow compile found in test case for PR28914 with large
array size. Constructor related.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20923
--- Additional Comments From tobi at gcc dot gnu dot org 2005-05-19 22:19
---
One more thing I forgot to mention: for n = 100 the .original dump looks like
this:
int4 offset.1;
struct array1_int4 atmp.0;
atmp.0.dtype = 265;
atmp.0.dim[0].stride = 1;
atmp.0.dim[0].lb
--- Additional Comments From tobi at gcc dot gnu dot org 2005-05-19 22:14
---
ugh, it is quadratic, only the inner array constructor gets expanded. And this
is where the <= 100 restriction I alluded to above comes in. For n = 100 the
relevant line from the -fdump-parse-tree output looks
--- Additional Comments From tobi at gcc dot gnu dot org 2005-05-19 22:09
---
The time behavior is strictly linear BTW:
n = 100:
real0m0.604s
user0m0.485s
sys 0m0.021s
n = 1000:
real1m0.860s
user0m49.055s
sys 0m0.078s
(the array grows quadratically with n)
One t
--- Additional Comments From tobi at gcc dot gnu dot org 2005-05-19 17:41
---
Confirmed. This is because the array constructor is expanded at compile-time.
If the constructor were used in an initialization we would abort, IIRC.
--
What|Removed |Adde
