[Bug c/66903] The gcc 4.9.2 crashes when processing declarations such as: int (( ... (x) ... ))

["speirofr at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66903

--- Comment #4 from Salva Peiró <speirofr at gmail dot com> ---
Confirmed, the cause of the crash is the parser 
_cpp_lex_direct() consuming the default 8 MB Linux stack.

Indeed, ulimit -s shows the stack size limit is set to 8192 KB,
After recompiling with ulimit -s unlimited, the gcc compilation 
succeeds without crashes.

Thanks for the explanation & the time to look at this,
PS: I raised the issue mainly because I was unsure of causes that lead to the
crash.
>From gcc-bugs-return-492771-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Jul 19 11:42:57 2015
Return-Path: <gcc-bugs-return-492771-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 59782 invoked by alias); 19 Jul 2015 11:42:56 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 59743 invoked by uid 48); 19 Jul 2015 11:42:51 -0000
From: "david.abdurachmanov at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/63304] Aarch64 pc-relative load offset out of range
Date: Sun, 19 Jul 2015 11:42:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords: assemble-failure
X-Bugzilla-Severity: normal
X-Bugzilla-Who: david.abdurachmanov at gmail dot com
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P5
X-Bugzilla-Assigned-To: pinskia at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-63304-4-Mvxk28oQY8@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-63304-4@http.gcc.gnu.org/bugzilla/>
References: <bug-63304-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-07/txt/msg01661.txt.bz2
Content-length: 1509

https://gcc.gnu.org/bugzilla/show_bug.cgi?idc304

--- Comment #14 from David Abdurachmanov <david.abdurachmanov at gmail dot com> ---
I hit another two cases of this.

1. g2root tool, which converts GEANT geometry to ROOT geometry. It create a
single function, which contains lots of descriptions of material, shapes, etc.
all describing some 3D objects and physical properties. These can be very huge.

Also could think of MILL computing as possible example. They use C++ as they
assembler (at least for simulation). Thus you have something like:

void somefunc(void) {
  add(b0, b1);
  add(b2, b3);
  ...
}

IIRC, by compiling it they generate a simulator to run this program on specific
CPU.

2. mcfm 6.3 package, to be precise: mcfm-6.3/src/WW/triangle11new.f

triangle11new.s: Assembler messages:
triangle11new.s:587: Error: pc-relative load offset out of range
triangle11new.s:592: Error: pc-relative load offset out of range

..
   587         ldr     x0, .LC2
   588         fmov    d0, x2
   589         fmov    d1, x0
   590         fdiv    d0, d0, d1
   591         fmov    x2, d0
   592         ldr     x0, .LC2
..

346645 .LC2:
346646         .word   0
346647         .word   1073741824
346648         .align  3
..

Distance between ldr instruction and .LC2 is 346058 assembly lines.

Here is the source file:
https://github.com/cms-externals/MCFM/blob/master/src/WW/triangle11new.f (just
1355 sloc).

It's those huge computations, which are killing it. Similar issue as in
OpenLoops package.