Re: gcc-4.6.3 ICE

Re: gcc-4.6.3 ICE

[Dennis Clarke]

>> 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=vindex&search=0x1D936C72FA35B44B
+-------------------------+-----------------------------------+
| Dennis Clarke           | Solaris and Linux and Open Source |
| dclarke@blastwave.org   | Respect for open standards.       |
+-------------------------+-----------------------------------+

Re: gcc-4.6.3 ICE

[Joseph S. Myers]

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
joseph@codesourcery.com

Re: gcc-4.6.3 ICE

[Rainer Orth]

"Joseph S. Myers" <joseph@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

[Ian Lance Taylor]

Rainer Orth <ro@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

[Dennis Clarke]

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

Re: gcc-4.6.3 ICE

[Jonathan Wakely]

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.
>
> Hrmmmm, 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

[Dennis Clarke]

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

Hrmmmm, 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=vindex&search=0x1D936C72FA35B44B
+-------------------------+-----------------------------------+
| Dennis Clarke           | Solaris and Linux and Open Source |
| dclarke@blastwave.org   | Respect for open standards.       |
+-------------------------+-----------------------------------+

Re: gcc-4.6.3 ICE

[Jonathan Wakely]

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

gcc-4.6.3 ICE

[Dennis Clarke]

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.


What would the procedure for that be ?



-- 
--
http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x1D936C72FA35B44B
+-------------------------+-----------------------------------+
| Dennis Clarke           | Solaris and Linux and Open Source |
| dclarke@blastwave.org   | Respect for open standards.       |
+-------------------------+-----------------------------------+