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