From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27242 invoked by alias); 11 Feb 2015 10:11:31 -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 27184 invoked by uid 48); 11 Feb 2015 10:11:28 -0000 From: "conchur at web dot de" To: gcc-bugs@gcc.gnu.org Subject: [Bug lto/65015] New: LTO produces randomly ordered debug information Date: Wed, 11 Feb 2015 10:11:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: lto X-Bugzilla-Version: 4.9.2 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: conchur at web dot de 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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter 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-02/txt/msg01140.txt.bz2 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D65015 Bug ID: 65015 Summary: LTO produces randomly ordered debug information Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: conchur at web dot de I was discussing with the Debian Reproducible Builds people some problem th= at I've noticed (only) with LTO builds. The build id (and debug link) was chan= ging all the time and J=C3=A9r=C3=A9my Bobbio suggested that one reason for this= problem are the odd filenames in the debug sections. I was able to workaround this special problem by using -flto-partition=3Dno= ne But now I still have differences in the debug sections. I tried to narrow it down, uncompressed it and found out that both files have the same size. And things like the debug_str sections have common parts but oddly (random?) ordered. This currently makes LTO unsuitable for reproducible builds on Debian (amd6= 4, and most likely all other architectures). I was not able to find any related bug in the meta bug #47819. Maybe it sho= uld be added there. My discussion of the findings can be found at http://lists.alioth.debian.org/pipermail/reproducible-builds/Week-of-Mon-20= 150209/000933.html >>From gcc-bugs-return-476806-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Feb 11 10:11:18 2015 Return-Path: Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 26996 invoked by alias); 11 Feb 2015 10:11:18 -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 26921 invoked by uid 48); 11 Feb 2015 10:11:15 -0000 From: "dcb314 at hotmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/64824] ICE in gimple verification Date: Wed, 11 Feb 2015 10:11:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: middle-end X-Bugzilla-Version: 5.0 X-Bugzilla-Keywords: openacc, openmp X-Bugzilla-Severity: normal X-Bugzilla-Who: dcb314 at hotmail dot com X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: jakub 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-02/txt/msg01139.txt.bz2 Content-length: 360 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64824 --- Comment #6 from David Binderman --- (In reply to Jakub Jelinek from comment #5) > What does #c3 have to do with this? Same ice, so I guessed same problem. >I don't see any OpenMP pragmas in your code, therefore it can't be related to >this. File a new PR? Done. #65014