From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32160 invoked by alias); 18 Nov 2014 16:13:20 -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 32110 invoked by uid 48); 18 Nov 2014 16:13:17 -0000 From: "fxcoudert at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/63937] [5 Regression] Compiling large arrays fails Date: Tue, 18 Nov 2014 16:13: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: X-Bugzilla-Severity: normal X-Bugzilla-Who: fxcoudert at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 5.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cf_gcctarget bug_status cf_reconfirmed_on component cc cf_gcchost everconfirmed short_desc target_milestone cf_gccbuild 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: 2014-11/txt/msg01724.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63937 Francois-Xavier Coudert changed: What |Removed |Added ---------------------------------------------------------------------------- Target| |x86_64-apple-darwin14 Status|UNCONFIRMED |NEW Last reconfirmed| |2014-11-18 Component|fortran |target CC| |amylaar at gcc dot gnu.org, | |jgreenhalgh at gcc dot gnu.org Host| |x86_64-apple-darwin14 Ever confirmed|0 |1 Summary|[5 Regression] Compiling a |[5 Regression] Compiling |very simple fortran code |large arrays fails |fails. | Target Milestone|--- |5.0 Build| |x86_64-apple-darwin14 --- Comment #2 from Francois-Xavier Coudert --- I can confirm, and can provide a C testcase (on x86_64-apple-darwin14 with trunk r217694): $ cat a.c void foo (void) { int v[1073741825] = {}; } $ ./bin/gcc a.c [blows up] And I know it sounds weird, but the behavior depends on the exact value of the array size, in a deterministic manner. It fails for 1073741825 (every time), but works with both 1003741825 (smaller) and 1173741825 (bigger). I stopped it at some random moments in this long "freeze", and the stable part of the backtrace is: frame #4: 0x00000001005c662a cc1`store_by_pieces_1 + 183 at expr.c:2721 frame #5: 0x00000001005c6573 cc1`store_by_pieces_1(data=0x00007fff5fbff190, align=64) + 275 frame #6: 0x00000001005d98d0 cc1`clear_storage_hints(rtx_def*, rtx_def*, block_op_methods, unsigned int, long long, unsigned long long, unsigned long long, unsigned long long) + 58 at expr.c:2605 frame #7: 0x00000001005d9896 cc1`clear_storage_hints(object=0x0000000142e44738, size=0x0000000142e46060, method=BLOCK_OP_NORMAL, expected_align=0, expected_size=-1, min_size=4294967300, max_size=4294967300, probable_max_size=4294967300) + 486 I'm not sure when that change occurred, but the only thing related to "store_by_pieces" I could find in the ChangeLog is a series of commits: 2014-11-01 James Greenhalgh