From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25102 invoked by alias); 27 May 2015 19:15:46 -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 25062 invoked by uid 48); 27 May 2015 19:15:43 -0000 From: "dcb314 at hotmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/66314] New: ice in verify_loop_structure Date: Wed, 27 May 2015 19:15:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c X-Bugzilla-Version: 6.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: dcb314 at hotmail 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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone attachments.created Message-ID: 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-05/txt/msg02271.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D66314 Bug ID: 66314 Summary: ice in verify_loop_structure Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 35637 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=3D35637&action=3Dedit C source code For trunk gcc dated 20150527 crypto/asymmetric_keys/pkcs7_trust.c: In function =E2=80=98pkcs7_validate_t= rust=E2=80=99: crypto/asymmetric_keys/pkcs7_trust.c:168:5: error: size of loop 2 should be= 36, not 38 int pkcs7_validate_trust(struct pkcs7_message *pkcs7, ^ crypto/asymmetric_keys/pkcs7_trust.c:168:5: internal compiler error: in verify_loop_structure, at cfgloop.c:1662 0x7166e3 verify_loop_structure() ../../src/trunk/gcc/cfgloop.c:1662 0xa13f47 loop_optimizer_init(unsigned int) ../../src/trunk/gcc/loop-init.c:124 0xe4a53a execute_vrp ../../src/trunk/gcc/tree-vrp.c:10377 0xe4a53a execute ../../src/trunk/gcc/tree-vrp.c:10474 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See for instructions. Flags -std=3Dgnu89 -Os -fprofile-arcs -fsanitize=3Dkernel-address required. Code derived from Linux kernel, so probably quite important. >>From gcc-bugs-return-487432-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed May 27 19:16:28 2015 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 26065 invoked by alias); 27 May 2015 19:16:28 -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 26030 invoked by uid 55); 27 May 2015 19:16:23 -0000 From: "andi at firstfloor dot org" To: gcc-bugs@gcc.gnu.org Subject: [Bug lto/66305] -ffat-lto-objects create unreproducible objects Date: Wed, 27 May 2015 19:16:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: lto X-Bugzilla-Version: 5.1.1 X-Bugzilla-Keywords: lto X-Bugzilla-Severity: normal X-Bugzilla-Who: andi at firstfloor dot org 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: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2015-05/txt/msg02272.txt.bz2 Content-length: 1201 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66305 --- Comment #4 from andi at firstfloor dot org --- > --- Comment #3 from lunar at debian dot org --- > Richard Biener: > > I think they become deterministic with -frandom-seed=0 for example. > > They are not deterministic to support partial linking of LTO objects as far > > as I know. > > They are indeed reproducible with `-frandom-seed=0`. But I guess there's a > downside to that, right? The downside is that incremential linking (ld -r) does not work. But the random seed is used for other things in gcc too, so you may have other problems too. > > similar, which would be a bit more deterministic, but there are still > > ways this could break (e.g. if someone copies object files around) > > Would using a hash over the section content work? In any cases, in the context > of Debian (this applies for FreeBSD as well), we have a canonical build path > so it would probably be fine to use it as the source of the hash. > > I guess one could already do this without further help by giving the > build path to `-frandom-seed=`. This only would need some Makefile trickery. Yes. It would probably be easier in gcc, e.g. with a new option.