[forwarded from http://bugs.debian.org/484569] seen with 4.3.1 20080523, works with 4.2.4. Replacing -O2 with -O1 lets the build succeed. Matthias g++ -Wall -g -O2 -save-temps -pthread greycstoration4gimp.ii timed out after 150min on various buildds.
In function cimg_library::CImg<T>& cimg_library::CImg<T>::blur_patch(unsigned int, float, float, unsigned int, bool), which contains some number of loops from macro expansion stuff. -fno-tree-pre "fixes" it. phi-translation is dog slow.
Created attachment 15722 [details] testcase
4.3.1 is being released, adjusting target milestone.
Created attachment 15728 [details] smaller testcase
4.3.2 is released, changing milestones to 4.3.3.
It seems to work on the trunk now. I'm trying to reduce it on the branch.
We take a long time in compute_antic in the loop for (i = 0; i < last_basic_block - NUM_FIXED_BLOCKS; i++) { if (TEST_BIT (changed_blocks, postorder[i])) { basic_block block = BASIC_BLOCK (postorder[i]); changed |= compute_antic_aux (block, TEST_BIT (has_abnormal_preds, block->index)); } } (gdb) print cfun->cfg->x_last_basic_block $22 = 3220 and some invocations of compute_antic_aux take a really long time during phi_translate_set because the to translate set is really large (it has in one case 11885 elements). probably not much to do here ...
GCC 4.3.3 is being released, adjusting target milestone.
*** Bug 39210 has been marked as a duplicate of this bug. ***
GCC 4.3.4 is being released, adjusting target milestone.
(In reply to comment #10) > GCC 4.3.4 is being released, adjusting target milestone. Very non-scientific benchmark: Did compile latest gmic-1.3.4.0 on a 2xL5540 system (plenty of RAM) with make -j8 and compile flags: -O3 --param max-inline-insns-auto=200 -ffast-math -funroll-loops -ftree-vectorize Times (in seconds, user, elapsed): 4.3.5: 1263u, 377e w/ -fno-tree-pre: 755u, 202e 4.4.4: 1022u, 311e w/ -fno-tree-pre: 996u, 284e 4.5.0: 2325u, 615e w/ -fno-tree-pre: 1974u, 543e Note that this is in contrast to earlier observations that 4.4/4.5 did do much better than 4.3. Don't know whether that's caused by changed gmic code or whether we have regressed in 4.5. Let me know if you want me to pick one file that takes particularly long to compile and investigate further.
Well for 4.5, make sure you configured with --enable-checking=release; otherwise it is not a fair comparison.
> Well for 4.5, make sure you configured with --enable-checking=release; > otherwise it is not a fair comparison. Did not change anything unfortunately :-( (I have enabled --enable-lto in case this matters, though I have not used any compile time flag to make use of it ...)
Subject: Re: [4.3 Regression] very long compile-time in PRE building gimp-plugin-registry On Fri, 19 Mar 2010, kurt at garloff dot de wrote: > ------- Comment #11 from kurt at garloff dot de 2010-03-19 00:34 ------- > (In reply to comment #10) > > GCC 4.3.4 is being released, adjusting target milestone. > > Very non-scientific benchmark: > Did compile latest gmic-1.3.4.0 on a 2xL5540 system (plenty of RAM) with make > -j8 and compile flags: > -O3 --param max-inline-insns-auto=200 -ffast-math -funroll-loops > -ftree-vectorize > Times (in seconds, user, elapsed): > 4.3.5: 1263u, 377e > w/ -fno-tree-pre: 755u, 202e > 4.4.4: 1022u, 311e > w/ -fno-tree-pre: 996u, 284e > 4.5.0: 2325u, 615e > w/ -fno-tree-pre: 1974u, 543e > > Note that this is in contrast to earlier observations that 4.4/4.5 did do much > better than 4.3. Don't know whether that's caused by changed gmic code or > whether we have regressed in 4.5. Let me know if you want me to pick one file > that takes particularly long to compile and investigate further. This bug was about PRE causing compile-time issues at -O2 which is what was investigated and fixed for the testcases attached to this PR. I see, for -O2 and the CImg.C testcase (just using openSUSE packages from devel:gcc): 4.3.4 (r152973): stopped after 4min 4.4.2 (r155966): 68s 4.5.0 (r157384): 74s also see PR43415 for a similar problem where I am about to commit a patch. If you can provide a testcase for plain -O3 [-ffast-math -funroll-loops] being slow it would be appropriate to open a new bugreport for it. Thanks, Richard.
(In reply to comment #14) > Subject: Re: [4.3 Regression] very long > compile-time in PRE building gimp-plugin-registry > > On Fri, 19 Mar 2010, kurt at garloff dot de wrote: > > > ------- Comment #11 from kurt at garloff dot de 2010-03-19 00:34 ------- > > (In reply to comment #10) > > > GCC 4.3.4 is being released, adjusting target milestone. > > > > Very non-scientific benchmark: > > Did compile latest gmic-1.3.4.0 on a 2xL5540 system (plenty of RAM) with make > > -j8 and compile flags: > > -O3 --param max-inline-insns-auto=200 -ffast-math -funroll-loops > > -ftree-vectorize > > Times (in seconds, user, elapsed): > > 4.3.5: 1263u, 377e > > w/ -fno-tree-pre: 755u, 202e > > 4.4.4: 1022u, 311e > > w/ -fno-tree-pre: 996u, 284e > > 4.5.0: 2325u, 615e > > w/ -fno-tree-pre: 1974u, 543e > > > > Note that this is in contrast to earlier observations that 4.4/4.5 did do much > > better than 4.3. Don't know whether that's caused by changed gmic code or > > whether we have regressed in 4.5. Let me know if you want me to pick one file > > that takes particularly long to compile and investigate further. > > This bug was about PRE causing compile-time issues at -O2 which is > what was investigated and fixed for the testcases attached to this PR. > > I see, for -O2 and the CImg.C testcase (just using openSUSE packages > from devel:gcc): > > 4.3.4 (r152973): stopped after 4min > 4.4.2 (r155966): 68s > 4.5.0 (r157384): 74s > > also see PR43415 for a similar problem where I am about to commit a > patch. > > If you can provide a testcase for plain -O3 [-ffast-math -funroll-loops] > being slow it would be appropriate to open a new bugreport for it. Oh, and btw check if you build with debuginfo enabled. With GCC 4.5 we can spend quite some extra time producing "good" debug information.
GCC 4.3.5 is being released, adjusting target milestone.
Fixed for 4.4.0.