public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
From: ghazi@caip.rutgers.edu
To: gcc-gnats@gcc.gnu.org
Cc: rth@redhat.com, davem@redhat.com, jakub@redhat.com
Subject: target/10349: sparc64-sun-solaris2.7 testsuite failure in g++.dg/parse/stack1.C
Date: Tue, 08 Apr 2003 15:56:00 -0000	[thread overview]
Message-ID: <20030408154954.17981.qmail@sources.redhat.com> (raw)


>Number:         10349
>Category:       target
>Synopsis:       sparc64-sun-solaris2.7 testsuite failure in g++.dg/parse/stack1.C
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          ice-on-legal-code
>Submitter-Id:   net
>Arrival-Date:   Tue Apr 08 15:56:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     Kaveh Ghazi
>Release:        gcc version 3.3 20030408 (prerelease)
>Organization:
>Environment:
sparc64-sun-solaris2.7
>Description:
As noted here:
http://gcc.gnu.org/ml/gcc-testresults/2003-04/msg00483.html
I'm getting testsuite failures in gcc-3.3 on sparc64-sun-solaris2.7 for g++.dg/parse/stack1.C.

The compiler crashes with a segmentation fault compiling the testcase.  After some investigation I determined that the problem is that it is running out of stack space.

Solaris2.7 (and 2.8) seem to come configured with stacksize set to 8192K.  When I raise it to 16384K the testcase compiles.  That seems like an excessively large amount of stack space consumption, given that the regular v7 sparc compiles it in as low as 2048K stack.  

It's not affected by the GC tuning parameters, i.e. large and small RAM systems get the same crash at stacksize 8192K.

A fix for the original problem was applied (see PR2161) but I'm getting failures in this configuration.

>How-To-Repeat:
The original PR fix involved bison to some degree.  I'm using bison 1.75 if that matters.  

I cannot get the testcase to fail in a 32->64 cross compiler.  A native sparc64-sun-solaris2.7 build with stacksize set to 8192 (the default I believe on solaris2.7) seems to be required.  You might be able to get it to fail on other sparc64 platforms with limited stacksize, I can't say for sure.

Simply compile stack1.C with -S and note the compiler crash.  Change stacksize to 16384K and it succeeds.

/* PR c/2161: parser stack overflow.  */
/* { dg-do compile } */

#define ONE     else if (0) { }
#define TEN     ONE ONE ONE ONE ONE ONE ONE ONE ONE ONE
#define HUN     TEN TEN TEN TEN TEN TEN TEN TEN TEN TEN
#define THOU    HUN HUN HUN HUN HUN HUN HUN HUN HUN HUN

void foo()
{
  if (0) { }
  /* 11,000 else if's.  */
  THOU THOU THOU THOU THOU THOU THOU THOU THOU THOU THOU
}
>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:


                 reply	other threads:[~2003-04-08 15:56 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20030408154954.17981.qmail@sources.redhat.com \
    --to=ghazi@caip.rutgers.edu \
    --cc=davem@redhat.com \
    --cc=gcc-gnats@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=rth@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).