Re: gcc-4.6.3 ICE
Thank you for the quick reply. OKay, follow up from a few days ago. I ran the testsuite again however with a stack size of 32Mb and now there are no ICE issues. See : http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02401.html What I find interesting is why we see an internal compiler error as opposed to something more reasonable when the user stack size is too small. Really, this is not a compiler fault at all but a user environment issue and thus the ICE is a false alarm. dc -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindexsearch=0x1D936C72FA35B44B +-+---+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
Re: gcc-4.6.3 ICE
On Wed, 21 Mar 2012, Dennis Clarke wrote: What I find interesting is why we see an internal compiler error as opposed to something more reasonable when the user stack size is too small. Really, this is not a compiler fault at all but a user environment issue and thus the ICE is a false alarm. I suppose we could use sigaltstack where available and a signal handler to detect stack overflow on suitable hosts to give a better message. It ought to be possible to use -fsplit-stack to avoid stack overflow - it would be interesting to know if that works (if GCC is built with -fsplit-stack, and linked with gold, on a host for which this is properly supported) and how it affects GCC's performance. -- Joseph S. Myers jos...@codesourcery.com
Re: gcc-4.6.3 ICE
Joseph S. Myers jos...@codesourcery.com writes: On Wed, 21 Mar 2012, Dennis Clarke wrote: What I find interesting is why we see an internal compiler error as opposed to something more reasonable when the user stack size is too small. Really, this is not a compiler fault at all but a user environment issue and thus the ICE is a false alarm. Btw., the problem is long known: PR c/35608. I suppose we could use sigaltstack where available and a signal handler to detect stack overflow on suitable hosts to give a better message. Agreed. It ought to be possible to use -fsplit-stack to avoid stack overflow - it would be interesting to know if that works (if GCC is built with -fsplit-stack, and linked with gold, on a host for which this is properly supported) and how it affects GCC's performance. That's a Linux-only option, unfortunately. I asked the Solaris engineers about implementing split-stack support, but they rejected it for the complexity. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: gcc-4.6.3 ICE
Rainer Orth r...@cebitec.uni-bielefeld.de writes: That's a Linux-only option, unfortunately. I asked the Solaris engineers about implementing split-stack support, but they rejected it for the complexity. Wimps. The split-stack support is simpler than than TLS support. Not that I really think gcc should use split-stack, split-stack is more for threaded programs. I think for gcc sigaltstack is a fine solution. Ian
Re: gcc-4.6.3 ICE
On 19 March 2012 14:56, Dennis Clarke wrote: thus : http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02155.html === gcc tests === Running target unix FAIL: gcc.c-torture/compile/limits-exprparen.c -O0 (internal compiler error) FAIL: gcc.c-torture/compile/limits-exprparen.c -O0 (test for excess errors) FAIL: gcc.c-torture/compile/limits-exprparen.c -O1 (internal compiler error) FAIL: gcc.c-torture/compile/limits-exprparen.c -O1 (test for excess errors) FAIL: gcc.c-torture/compile/limits-exprparen.c -O2 (internal compiler error) FAIL: gcc.c-torture/compile/limits-exprparen.c -O2 (test for excess errors) FAIL: gcc.c-torture/compile/limits-exprparen.c -O3 -fomit-frame-pointer (internal compiler error) FAIL: gcc.c-torture/compile/limits-exprparen.c -O3 -fomit-frame-pointer (test for excess errors) FAIL: gcc.c-torture/compile/limits-exprparen.c -O3 -g (internal compiler error) FAIL: gcc.c-torture/compile/limits-exprparen.c -O3 -g (test for excess errors) FAIL: gcc.c-torture/compile/limits-exprparen.c -Os (internal compiler error) I'd like to extend my stack size a bit and re-run the gcc tests only. At the very least I'd like to see gcc.c-torture/compile/limits-exprparen.c run again. In detail. The full output of those tests should still be in a .log file somewhere under the build dir. What would the procedure for that be ? See http://gcc.gnu.org/install/test.html and http://gcc.gnu.org/wiki/HowToPrepareATestcase for commands to run specific tests. I think you should be able to do something like: make check RUNTESTFLAGS=compile.exp=gcc.c-torture/compile/limits-exprparen.c
Re: gcc-4.6.3 ICE
On 19 March 2012 14:56, Dennis Clarke wrote: thus : http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg02155.html === gcc tests === Running target unix FAIL: gcc.c-torture/compile/limits-exprparen.c -O0 (internal compiler error) FAIL: gcc.c-torture/compile/limits-exprparen.c -O0 (test for excess errors) FAIL: gcc.c-torture/compile/limits-exprparen.c -O1 (internal compiler error) FAIL: gcc.c-torture/compile/limits-exprparen.c -O1 (test for excess errors) FAIL: gcc.c-torture/compile/limits-exprparen.c -O2 (internal compiler error) FAIL: gcc.c-torture/compile/limits-exprparen.c -O2 (test for excess errors) FAIL: gcc.c-torture/compile/limits-exprparen.c -O3 -fomit-frame-pointer (internal compiler error) FAIL: gcc.c-torture/compile/limits-exprparen.c -O3 -fomit-frame-pointer (test for excess errors) FAIL: gcc.c-torture/compile/limits-exprparen.c -O3 -g (internal compiler error) FAIL: gcc.c-torture/compile/limits-exprparen.c -O3 -g (test for excess errors) FAIL: gcc.c-torture/compile/limits-exprparen.c -Os (internal compiler error) I'd like to extend my stack size a bit and re-run the gcc tests only. At the very least I'd like to see gcc.c-torture/compile/limits-exprparen.c run again. In detail. The full output of those tests should still be in a .log file somewhere under the build dir. What would the procedure for that be ? See http://gcc.gnu.org/install/test.html and http://gcc.gnu.org/wiki/HowToPrepareATestcase for commands to run specific tests. I think you should be able to do something like: make check RUNTESTFLAGS=compile.exp=gcc.c-torture/compile/limits-exprparen.c Thank you for the quick reply. Hr, tried that and didn't get very far probably because the srcdir is at ../gcc-4.6.3 which is where I see the familiar old friend : titan-i386-SunOS5.8 $ cat ../gcc-4.6.3/gcc/testsuite/gcc.c-torture/compile/limits-exprparen.c #define LBR1 ( ( ( ( ( ( ( ( ( ( #define LBR2 LBR1 LBR1 LBR1 LBR1 LBR1 LBR1 LBR1 LBR1 LBR1 LBR1 #define LBR3 LBR2 LBR2 LBR2 LBR2 LBR2 LBR2 LBR2 LBR2 LBR2 LBR2 #define LBR4 LBR3 LBR3 LBR3 LBR3 LBR3 LBR3 LBR3 LBR3 LBR3 LBR3 #define LBR5 LBR4 LBR4 LBR4 LBR4 LBR4 LBR4 LBR4 LBR4 LBR4 LBR4 #define LBR6 LBR5 LBR5 LBR5 LBR5 LBR5 LBR5 LBR5 LBR5 LBR5 LBR5 #define RBR1 ) ) ) ) ) ) ) ) ) ) #define RBR2 RBR1 RBR1 RBR1 RBR1 RBR1 RBR1 RBR1 RBR1 RBR1 RBR1 #define RBR3 RBR2 RBR2 RBR2 RBR2 RBR2 RBR2 RBR2 RBR2 RBR2 RBR2 #define RBR4 RBR3 RBR3 RBR3 RBR3 RBR3 RBR3 RBR3 RBR3 RBR3 RBR3 #define RBR5 RBR4 RBR4 RBR4 RBR4 RBR4 RBR4 RBR4 RBR4 RBR4 RBR4 #define RBR6 RBR5 RBR5 RBR5 RBR5 RBR5 RBR5 RBR5 RBR5 RBR5 RBR5 int q5_var = LBR4 0 RBR4; This really comes down to the users stack size and a ulimit -s X for X=16384 or even 32768 solves it if I recall. I think I may just run the whole testsuite again, there are other pieces of ICE that I'd like to see melt away. dc -- -- http://pgp.mit.edu:11371/pks/lookup?op=vindexsearch=0x1D936C72FA35B44B +-+---+ | Dennis Clarke | Solaris and Linux and Open Source | | dcla...@blastwave.org | Respect for open standards. | +-+---+
Re: gcc-4.6.3 ICE
On 19 March 2012 15:30, Dennis Clarke wrote: I think you should be able to do something like: make check RUNTESTFLAGS=compile.exp=gcc.c-torture/compile/limits-exprparen.c Thank you for the quick reply. Hr, tried that and didn't get very far probably because the srcdir is at ../gcc-4.6.3 I don't think that's the problem. Maybe you need make check RUNTESTFLAGS=compile.exp=limits-exprparen.c or make check RUNTESTFLAGS=compile.exp=*/limits-exprparen.c or some other variation on that theme.
Re: gcc-4.6.3 ICE
Hr, tried that and didn't get very far probably because the srcdir is at ../gcc-4.6.3 I don't think that's the problem. Maybe you need make check RUNTESTFLAGS=compile.exp=limits-exprparen.c or make check RUNTESTFLAGS=compile.exp=*/limits-exprparen.c or some other variation on that theme. Well, too late now, I already incanted make -j 2 -k check and can expect results in a few hours. Thank you for helping. dc
