From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3216 invoked by alias); 19 Jul 2015 09:16:19 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 3198 invoked by uid 48); 19 Jul 2015 09:16:15 -0000 From: "speirofr at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/66903] The gcc 4.9.2 crashes when processing declarations such as: int (( ... (x) ... )) Date: Sun, 19 Jul 2015 09:16:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c X-Bugzilla-Version: 4.9.2 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: speirofr at gmail dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-07/txt/msg01660.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D66903 --- Comment #4 from Salva Peir=C3=B3 --- Confirmed, the cause of the crash is the parser=20 _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=20 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 t= he crash. >>From gcc-bugs-return-492771-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Jul 19 11:42:57 2015 Return-Path: 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: List-Archive: List-Post: List-Help: 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" 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: In-Reply-To: References: 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?id=63304 --- Comment #14 from David Abdurachmanov --- 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.