From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26960 invoked by alias); 17 Jun 2013 21:46:12 -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 26926 invoked by uid 48); 17 Jun 2013 21:46:06 -0000 From: "marxin.liska at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/57208] Latest chromium compilation fails with enabled LTO Date: Mon, 17 Jun 2013 21:46: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.8.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: marxin.liska at gmail dot com X-Bugzilla-Status: UNCONFIRMED 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: 2013-06/txt/msg00934.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D57208 --- Comment #7 from Martin Li=C5=A1ka --- I've updated to latest gcc, all previous bugs are irrelevant: I mixed diffe= rent -Ox cflags and chromium build system is full of hacks (they use gold as a primary linker, but bfd is used for some stuff, I used just bfd in my compilation). gcc --version: gcc (GCC) 4.9.0 20130617 (experimental) I finally reached WPA stage of LTO, memory usage was about 8GB for ld and 1= 1 GB for lto1. lto1 was running for about 20 minutes and following error occured: lto1: error: ELF section name out of range lto1: internal compiler error: Segmentation fault 0x85e0bf crash_signal ../../gcc/toplev.c:333 0xd7f0dd htab_delete ../../libiberty/hashtab.c:419 0x50a41c lto_file_read ../../gcc/lto/lto.c:2824 0x50a41c read_cgraph_and_symbols ../../gcc/lto/lto.c:3401 0x50a41c lto_main() ../../gcc/lto/lto.c:3834 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See for instructions. lto-wrapper: g++ returned 1 exit status /home/marxin/gcc-mirror/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/ld: lto-wrapper failed collect2: error: ld returned 1 exit status ninja: build stopped: subcommand failed. Do you have any ideas? >>From gcc-bugs-return-424556-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jun 17 22:07:40 2013 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 8534 invoked by alias); 17 Jun 2013 22:07:39 -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 8460 invoked by uid 48); 17 Jun 2013 22:07:33 -0000 From: "furue at hawaii dot edu" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/57628] spurious error: division by zero in if statement Date: Mon, 17 Jun 2013 22:07:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 4.7.3 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: furue at hawaii dot edu X-Bugzilla-Status: RESOLVED 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: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2013-06/txt/msg00935.txt.bz2 Content-length: 672 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57628 --- Comment #16 from Ryo Furue --- (In reply to Steve Kargl from comment #12) > On Sun, Jun 16, 2013 at 11:33:49PM +0000, furue at hawaii dot edu wrote: > > > > Is this an inconsistency in the implementation of -no-range-check ? > > No. Then, what's the counterpart of -fno-range-check that takes care of such cases as sqrt? To repeat the code: real, parameter:: a = -1.0 if (a > 0) write(*,*) sqrt(a) With such a switch turned on, the compiler can replace sqrt(-1.0) with NaN and let the code pass. Or is it better to extend -fno-range-check to cover these cases, too? Cheers, Ryo