public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
* [Bug bootstrap/65537] New: [5 Regression]: --with-build-config=bootstrap-lto fails on CentOS 5.11 @ 2015-03-24 9:26 ubizjak at gmail dot com 2015-03-24 9:46 ` [Bug bootstrap/65537] " trippels at gcc dot gnu.org ` (8 more replies) 0 siblings, 9 replies; 10+ messages in thread From: ubizjak at gmail dot com @ 2015-03-24 9:26 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65537 Bug ID: 65537 Summary: [5 Regression]: --with-build-config=bootstrap-lto fails on CentOS 5.11 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: ubizjak at gmail dot com When configured with --with-build-config=bootstrap-lto, the bootstrap fails on CentOS 5.11 in libiberty with: /home/uros/gcc-build/./prev-gcc/gcc-ar -B/home/uros/gcc-build/./prev-gcc/ rc ./libiberty.a \ ./regex.o ./cplus-dem.o ./cp-demangle.o ./md5.o ./sha1.o ./alloca.o ./argv.o ./choose-temp.o ./concat.o ./cp-demint.o ./crc32.o ./d-demangle.o ./dwarfnames.o ./dyn-string.o ./fdmatch.o ./fibheap.o ./filename_cmp.o ./floatformat.o ./fnmatch.o ./fopen_unlocked.o ./getopt.o ./getopt1.o ./getpwd.o ./getruntime.o ./hashtab.o ./hex.o ./lbasename.o ./lrealpath.o ./make-relative-prefix.o ./make-temp-file.o ./objalloc.o ./obstack.o ./partition.o ./pexecute.o ./physmem.o ./pex-common.o ./pex-one.o ./pex-unix.o ./vprintf-support.o ./safe-ctype.o ./simple-object.o ./simple-object-coff.o ./simple-object-elf.o ./simple-object-mach-o.o ./simple-object-xcoff.o ./sort.o ./spaces.o ./splay-tree.o ./stack-limit.o ./strerror.o ./strsignal.o ./timeval-utils.o ./unlink-if-ordinary.o ./xasprintf.o ./xatexit.o ./xexit.o ./xmalloc.o ./xmemdup.o ./xstrdup.o ./xstrerror.o ./xstrndup.o ./xvasprintf.o ./mkstemps.o ./setproctitle.o /usr/bin/ar: illegal option -- - Usage: /usr/bin/ar [emulation options] [-]{dmpqrstx}[abcfilNoPsSuvV] [member-name] [count] archive-file file... /usr/bin/ar -M [<mri-script] commands: d - delete file(s) from the archive m[ab] - move file(s) in the archive p - print file(s) found in the archive q[f] - quick append file(s) to the archive r[ab][f][u] - replace existing or insert new file(s) into the archive t - display contents of archive x[o] - extract file(s) from the archive command specific modifiers: [a] - put file(s) after [member-name] [b] - put file(s) before [member-name] (same as [i]) [N] - use instance [count] of name [f] - truncate inserted file names [P] - use full path names when matching [o] - preserve original dates [u] - only replace files that are newer than current archive contents generic modifiers: [c] - do not warn if the library had to be created [s] - create an archive index (cf. ranlib) [S] - do not build a symbol table [v] - be verbose [V] - display the version number @<file> - read options from <file> emulation options: No emulation specific options /usr/bin/ar: supported targets: elf64-x86-64 elf32-i386 a.out-i386-linux efi-app-ia32 elf64-little elf64-big elf32-little elf32-big srec symbolsrec tekhex binary ihex gmake[3]: *** [libiberty.a] Error 1 gmake[3]: Leaving directory `/home/uros/gcc-build/libiberty' gmake[2]: *** [all-stage2-libiberty] Error 2 gmake[2]: Leaving directory `/home/uros/gcc-build' gmake[1]: *** [stage2-bubble] Error 2 gmake[1]: Leaving directory `/home/uros/gcc-build' gmake: *** [all] Error 2 The problem is with gcc-ar that unconditionally passes --plugin option to ar. This fails on older binutils, such as: $ ar --version GNU ar 2.17.50.0.6-26.el5 20061020 Copyright 2005 Free Software Foundation, Inc. LTO bootstrap worked a while ago, so this is a regression on 5.0 branch. ^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug bootstrap/65537] [5 Regression]: --with-build-config=bootstrap-lto fails on CentOS 5.11 2015-03-24 9:26 [Bug bootstrap/65537] New: [5 Regression]: --with-build-config=bootstrap-lto fails on CentOS 5.11 ubizjak at gmail dot com @ 2015-03-24 9:46 ` trippels at gcc dot gnu.org 2015-03-24 9:50 ` ubizjak at gmail dot com ` (7 subsequent siblings) 8 siblings, 0 replies; 10+ messages in thread From: trippels at gcc dot gnu.org @ 2015-03-24 9:46 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65537 Markus Trippelsdorf <trippels at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |trippels at gcc dot gnu.org --- Comment #1 from Markus Trippelsdorf <trippels at gcc dot gnu.org> --- GCC bootstrap now uses slim LTO object files. LTO bootstrap with slim LTO never worked with ar that doesn't support liblto_plugin. Update your binutils? Or maybe the minimal binutils version for LTO bootstrap should be mentioned on changes.html? ^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug bootstrap/65537] [5 Regression]: --with-build-config=bootstrap-lto fails on CentOS 5.11 2015-03-24 9:26 [Bug bootstrap/65537] New: [5 Regression]: --with-build-config=bootstrap-lto fails on CentOS 5.11 ubizjak at gmail dot com 2015-03-24 9:46 ` [Bug bootstrap/65537] " trippels at gcc dot gnu.org @ 2015-03-24 9:50 ` ubizjak at gmail dot com 2015-03-24 10:44 ` rguenth at gcc dot gnu.org ` (6 subsequent siblings) 8 siblings, 0 replies; 10+ messages in thread From: ubizjak at gmail dot com @ 2015-03-24 9:50 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65537 --- Comment #2 from Uroš Bizjak <ubizjak at gmail dot com> --- (In reply to Markus Trippelsdorf from comment #1) > Update your binutils? Not an option on a production system ... > Or maybe the minimal binutils version for LTO bootstrap should be mentioned > on changes.html? I can live with this, but considering that auto-host.h correctly determines #define HAVE_LTO_PLUGIN 0 perhaps an easy fallback to use fat LTO objects ca be implemented in this case. >From gcc-bugs-return-481353-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Mar 24 09:32:24 2015 Return-Path: <gcc-bugs-return-481353-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org> Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 44643 invoked by alias); 24 Mar 2015 09:32:24 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: <gcc-bugs.gcc.gnu.org> List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/> List-Post: <mailto:gcc-bugs@gcc.gnu.org> List-Help: <mailto:gcc-bugs-help@gcc.gnu.org> Sender: gcc-bugs-owner@gcc.gnu.org Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 44274 invoked by uid 55); 24 Mar 2015 09:32:20 -0000 From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/65517] [5 Regression] ICE: in get_loop_body, at cfgloop.c:856 Date: Tue, 24 Mar 2015 09:55: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: X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org X-Bugzilla-Target-Milestone: 5.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: <bug-65517-4-Ytn2ZemC3g@http.gcc.gnu.org/bugzilla/> In-Reply-To: <bug-65517-4@http.gcc.gnu.org/bugzilla/> References: <bug-65517-4@http.gcc.gnu.org/bugzilla/> 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-03/txt/msg02497.txt.bz2 Content-length: 619 https://gcc.gnu.org/bugzilla/show_bug.cgi?ide517 --- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> --- Author: rguenth Date: Tue Mar 24 09:31:48 2015 New Revision: 221619 URL: https://gcc.gnu.org/viewcvs?rev"1619&root=gcc&view=rev Log: 2015-03-24 Richard Biener <rguenther@suse.de> PR middle-end/65517 * tree-cfg.c (remove_edge_and_dominated_blocks): Mark loops for fixup if necessary. * gcc.dg/torture/pr65517.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr65517.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-cfg.c ^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug bootstrap/65537] [5 Regression]: --with-build-config=bootstrap-lto fails on CentOS 5.11 2015-03-24 9:26 [Bug bootstrap/65537] New: [5 Regression]: --with-build-config=bootstrap-lto fails on CentOS 5.11 ubizjak at gmail dot com 2015-03-24 9:46 ` [Bug bootstrap/65537] " trippels at gcc dot gnu.org 2015-03-24 9:50 ` ubizjak at gmail dot com @ 2015-03-24 10:44 ` rguenth at gcc dot gnu.org 2015-03-24 10:45 ` [Bug bootstrap/65537] [5 Regression] " rguenth at gcc dot gnu.org ` (5 subsequent siblings) 8 siblings, 0 replies; 10+ messages in thread From: rguenth at gcc dot gnu.org @ 2015-03-24 10:44 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65537 --- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> --- Well, simply add a config/bootstrap-lto-fat.mk? ^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug bootstrap/65537] [5 Regression] --with-build-config=bootstrap-lto fails on CentOS 5.11 2015-03-24 9:26 [Bug bootstrap/65537] New: [5 Regression]: --with-build-config=bootstrap-lto fails on CentOS 5.11 ubizjak at gmail dot com ` (2 preceding siblings ...) 2015-03-24 10:44 ` rguenth at gcc dot gnu.org @ 2015-03-24 10:45 ` rguenth at gcc dot gnu.org 2015-03-24 11:08 ` trippels at gcc dot gnu.org ` (4 subsequent siblings) 8 siblings, 0 replies; 10+ messages in thread From: rguenth at gcc dot gnu.org @ 2015-03-24 10:45 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65537 Richard Biener <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |documentation Target Milestone|--- |5.0 Summary|[5 Regression]: |[5 Regression] |--with-build-config=bootstr |--with-build-config=bootstr |ap-lto fails on CentOS 5.11 |ap-lto fails on CentOS 5.11 ^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug bootstrap/65537] [5 Regression] --with-build-config=bootstrap-lto fails on CentOS 5.11 2015-03-24 9:26 [Bug bootstrap/65537] New: [5 Regression]: --with-build-config=bootstrap-lto fails on CentOS 5.11 ubizjak at gmail dot com ` (3 preceding siblings ...) 2015-03-24 10:45 ` [Bug bootstrap/65537] [5 Regression] " rguenth at gcc dot gnu.org @ 2015-03-24 11:08 ` trippels at gcc dot gnu.org 2015-03-24 11:44 ` jakub at gcc dot gnu.org ` (3 subsequent siblings) 8 siblings, 0 replies; 10+ messages in thread From: trippels at gcc dot gnu.org @ 2015-03-24 11:08 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65537 --- Comment #4 from Markus Trippelsdorf <trippels at gcc dot gnu.org> --- Or something like: diff --git a/config/bootstrap-lto.mk b/config/bootstrap-lto.mk index 9e065e1d85a0..5e93ee848727 100644 --- a/config/bootstrap-lto.mk +++ b/config/bootstrap-lto.mk @@ -1,5 +1,10 @@ # This option enables LTO for stage2 and stage3 in slim mode +#if HAVE_LTO_PLUGIN == 0 +STAGE2_CFLAGS += -flto=jobserver -frandom-seed=1 -ffat-lto-objects +STAGE3_CFLAGS += -flto=jobserver -frandom-seed=1 -ffat-lto-objects +STAGEprofile_CFLAGS += -fno-lto +#else STAGE2_CFLAGS += -flto=jobserver -frandom-seed=1 STAGE3_CFLAGS += -flto=jobserver -frandom-seed=1 STAGEprofile_CFLAGS += -fno-lto @@ -11,3 +16,4 @@ LTO_RANLIB = $$r/$(HOST_SUBDIR)/prev-gcc/gcc-ranlib$(exeext) -B$$r/$(HOST_SUBDIR LTO_EXPORTS = AR="$(LTO_AR)"; export AR; \ RANLIB="$(LTO_RANLIB)"; export RANLIB; LTO_FLAGS_TO_PASS = AR="$(LTO_AR)" RANLIB="$(LTO_RANLIB)" +#endif ^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug bootstrap/65537] [5 Regression] --with-build-config=bootstrap-lto fails on CentOS 5.11 2015-03-24 9:26 [Bug bootstrap/65537] New: [5 Regression]: --with-build-config=bootstrap-lto fails on CentOS 5.11 ubizjak at gmail dot com ` (4 preceding siblings ...) 2015-03-24 11:08 ` trippels at gcc dot gnu.org @ 2015-03-24 11:44 ` jakub at gcc dot gnu.org 2015-03-24 12:36 ` ubizjak at gmail dot com ` (2 subsequent siblings) 8 siblings, 0 replies; 10+ messages in thread From: jakub at gcc dot gnu.org @ 2015-03-24 11:44 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65537 Jakub Jelinek <jakub at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> --- HAVE_LTO_PLUGIN is a gcc/configure macro, while you'd need that in a toplevel file...; or the check would need to be copied or moved to the toplevel configure, and somehow propagated to the bootstrap*.mk files. ^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug bootstrap/65537] [5 Regression] --with-build-config=bootstrap-lto fails on CentOS 5.11 2015-03-24 9:26 [Bug bootstrap/65537] New: [5 Regression]: --with-build-config=bootstrap-lto fails on CentOS 5.11 ubizjak at gmail dot com ` (5 preceding siblings ...) 2015-03-24 11:44 ` jakub at gcc dot gnu.org @ 2015-03-24 12:36 ` ubizjak at gmail dot com 2015-03-25 8:39 ` ubizjak at gmail dot com 2015-03-25 16:38 ` uros at gcc dot gnu.org 8 siblings, 0 replies; 10+ messages in thread From: ubizjak at gmail dot com @ 2015-03-24 12:36 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65537 --- Comment #6 from Uroš Bizjak <ubizjak at gmail dot com> --- I'm testing the following patch: --cut here-- Index: config/bootstrap-lto-noplugin.mk =================================================================== --- config/bootstrap-lto-noplugin.mk (revision 0) +++ config/bootstrap-lto-noplugin.mk (revision 0) @@ -0,0 +1,6 @@ +# This option enables LTO for stage2 and stage3 on +# hosts without linker plugin support. + +STAGE2_CFLAGS += -flto=jobserver -frandom-seed=1 -ffat-lto-objects +STAGE3_CFLAGS += -flto=jobserver -frandom-seed=1 -ffat-lto-objects +STAGEprofile_CFLAGS += -fno-lto --cut here-- BTW: The documentation for bootstrap-lto is inadequate, as it does not mention any plugin support assumption or list any linker version requirement. >From gcc-bugs-return-481411-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Mar 24 12:16:59 2015 Return-Path: <gcc-bugs-return-481411-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org> Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 78782 invoked by alias); 24 Mar 2015 12:16:59 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: <gcc-bugs.gcc.gnu.org> List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/> List-Post: <mailto:gcc-bugs@gcc.gnu.org> List-Help: <mailto:gcc-bugs-help@gcc.gnu.org> Sender: gcc-bugs-owner@gcc.gnu.org Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 77942 invoked by uid 48); 24 Mar 2015 12:16:50 -0000 From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug lto/65536] LTO line number information garbled Date: Tue, 24 Mar 2015 12:39: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.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: manu at gcc dot gnu.org 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: <bug-65536-4-A8Cmi2uSck@http.gcc.gnu.org/bugzilla/> In-Reply-To: <bug-65536-4@http.gcc.gnu.org/bugzilla/> References: <bug-65536-4@http.gcc.gnu.org/bugzilla/> 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-03/txt/msg02555.txt.bz2 Content-length: 2718 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536 --- Comment #5 from Manuel López-Ibáñez <manu at gcc dot gnu.org> --- (In reply to Richard Biener from comment #2) > The main issue with LTO is that it re-creates a combined linemap but in (most > of the time) quite awkward ordering (simply registering random-ordered > file:line:column entries by switching files/lines "appropriately"). > > I've argued that it would be better to stream those file:line:columns > separately so we can "sort" them before handing them over to libcpp for > linemap re-creation. If the lines or columns are out of order, then all bets are off. Line-map locations have to be allocated incrementally. If you switch between files a lot, then you are wasting a lot of memory unnecessarily, since switching requires creating a new line-map. How difficult would be to track on which file you are and simply have a line_table per file and switch the current line_table appropriately? > So currently we do, for each "file:line:column" location we stream in: > > if (file_change) > { > if (prev_file) > linemap_add (line_table, LC_LEAVE, false, NULL, 0); > > linemap_add (line_table, LC_ENTER, false, current_file, current_line); > } > else if (line_change) > linemap_line_start (line_table, current_line, current_col); > > return linemap_position_for_column (line_table, current_col); > > which of course puts a heavy load on the linemap encoding... According to line-map.h: /* Reason for creating a new line map with linemap_add. LC_ENTER is when including a new file, e.g. a #include directive in C. LC_LEAVE is when reaching a file's end. LC_RENAME is when a file name or line number changes for neither of the above reasons (e.g. a #line directive in C); Thus I'm not sure the above is really correct. If a single line_table is desirable, it probably should use LC_RENAME for different main files (as if they were concatenated and using #line). LC_LEAVE/LC_ENTER only makes sense for included files, which I presume are slightly different than concatenated files. line-map.c has code to make some erroneous cases "work": I think they should be replaced by linemap_assert_fails(), such that they trigger an assert when checking but they try to recover gracefully otherwise. How are the original locations stored on disk? > But it should definitely work (not sure what it does on line or file > "overflow"). I'm not sure lines or files can really overflow, but location_t can, and the only "fix" is that column numbers get disabled (highest location > 0x60000000), but there is nothing stopping it from really overflowing after that. >From gcc-bugs-return-481410-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Mar 24 12:15:15 2015 Return-Path: <gcc-bugs-return-481410-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org> Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 51078 invoked by alias); 24 Mar 2015 12:15:15 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: <gcc-bugs.gcc.gnu.org> List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/> List-Post: <mailto:gcc-bugs@gcc.gnu.org> List-Help: <mailto:gcc-bugs-help@gcc.gnu.org> Sender: gcc-bugs-owner@gcc.gnu.org Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 50986 invoked by uid 48); 24 Mar 2015 12:15:08 -0000 From: "marxin at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug lto/65536] LTO line number information garbled Date: Tue, 24 Mar 2015 12:39: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.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: marxin at gcc dot gnu.org 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: cc Message-ID: <bug-65536-4-yTTYNQUpow@http.gcc.gnu.org/bugzilla/> In-Reply-To: <bug-65536-4@http.gcc.gnu.org/bugzilla/> References: <bug-65536-4@http.gcc.gnu.org/bugzilla/> 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-03/txt/msg02554.txt.bz2 Content-length: 5604 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536 Martin Liška <marxin at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |marxin at gcc dot gnu.org --- Comment #4 from Martin Liška <marxin at gcc dot gnu.org> --- (In reply to Jan Hubicka from comment #0) > As shown in https://gcc.gnu.org/ml/gcc-patches/2015-03/msg01151.html > warnings seems to come out wrong with large programs. I did not manage to > reproduce it with small testcase. Columns tends to be 0 and line numbers > (somewhat) off usually pointing to the begging of type definition instead of > the field in question but sometimes they just point in further distance. > > This reproduce both on Fireofx and Chromium > > The problem goes away with: > > Index: lto-streamer-in.c > =================================================================== > --- lto-streamer-in.c (revision 221582) > +++ lto-streamer-in.c (working copy) > @@ -200,7 +200,7 @@ lto_input_location (struct bitpack_d *bp > if (column_change) > current_col = bp_unpack_var_len_unsigned (bp); > > - if (file_change) > + if (file_change || 1) > { > if (prev_file) > linemap_add (line_table, LC_LEAVE, false, NULL, 0); > > (which also quite significantly increases memory use). The warnings seems > to be right on beggining and gets worse at end, so I suspect it is some kind > of overflow in libcpp. > > The problem stays with: > > Index: lto-streamer-in.c > =================================================================== > --- lto-streamer-in.c (revision 221582) > +++ lto-streamer-in.c (working copy) > @@ -207,7 +207,7 @@ lto_input_location (struct bitpack_d *bp > > linemap_add (line_table, LC_ENTER, false, current_file, current_line); > } > - else if (line_change) > + else if (line_change || 1) > linemap_line_start (line_table, current_line, current_col); > > return linemap_position_for_column (line_table, current_col); > > One obvious thing is that linemap_line_start takes argument 3 to be max > column hint, but we pass current_col that is not cool. > > I see that libcpp seems to drop the column info after some threshold (that > is clearly too small for LTO) but why the line numbers are off? Unfortunately, following patch causes SEGFAULT: Program received signal SIGSEGV, Segmentation fault. memset () at ../sysdeps/x86_64/memset.S:80 80 ../sysdeps/x86_64/memset.S: No such file or directory. (gdb) bt #0 memset () at ../sysdeps/x86_64/memset.S:80 #1 0x0000000000ed8ebd in new_linemap (set=set@entry=0x7ffff7fee000, reason=reason@entry=LC_ENTER) at ../../libcpp/line-map.c:265 #2 0x0000000000ed9288 in linemap_add (set=0x7ffff7fee000, reason=reason@entry=LC_ENTER, sysp=sysp@entry=0, to_file=0x12d245f0 "../../ui/views/controls/image_view.h", to_line=92) at ../../libcpp/line-map.c:314 #3 0x000000000080d439 in lto_input_location (bp=<optimized out>, data_in=<optimized out>) at ../../gcc/lto-streamer-in.c:208 #4 0x0000000000a8ba06 in streamer_read_tree_bitfields (ib=ib@entry=0x7fffffffd620, data_in=data_in@entry=0xc3281b0, expr=expr@entry=0x7fff163d05e8) at ../../gcc/tree-streamer-in.c:506 #5 0x000000000080a572 in lto_read_tree_1 (ib=0x7fffffffd620, data_in=0xc3281b0, expr=0x7fff163d05e8) at ../../gcc/lto-streamer-in.c:1193 #6 0x000000000080a8e5 in lto_read_tree (hash=399977849, tag=<optimized out>, data_in=0xc3281b0, ib=0x7fffffffd620) at ../../gcc/lto-streamer-in.c:1230 #7 lto_input_tree_1 (ib=0x7fffffffd620, data_in=0xc3281b0, tag=<optimized out>, hash=399977849) at ../../gcc/lto-streamer-in.c:1349 #8 0x000000000080abe2 in lto_input_scc (ib=ib@entry=0x7fffffffd620, data_in=data_in@entry=0xc3281b0, len=len@entry=0x7fffffffd618, entry_len=entry_len@entry=0x7fffffffd61c) at ../../gcc/lto-streamer-in.c:1254 #9 0x00000000005b39b7 in lto_read_decls (decl_data=decl_data@entry=0x7fff1b99f000, data=data@entry=0x151de970, resolutions=..., resolutions@entry=...) at ../../gcc/lto/lto.c:1902 #10 0x00000000005b52ac in lto_file_finalize (file=<optimized out>, file_data=0x7fff1b99f000) at ../../gcc/lto/lto.c:2236 #11 lto_create_files_from_ids (count=<synthetic pointer>, file_data=0x7fff1b99f000, file=0xbf4b5f0) at ../../gcc/lto/lto.c:2246 #12 lto_file_read (count=<synthetic pointer>, resolution_file=<optimized out>, file=<optimized out>) at ../../gcc/lto/lto.c:2287 #13 read_cgraph_and_symbols (fnames=<optimized out>, nfiles=<optimized out>) at ../../gcc/lto/lto.c:2992 #14 lto_main () at ../../gcc/lto/lto.c:3462 #15 0x0000000000903592 in compile_file () at ../../gcc/toplev.c:594 #16 0x000000000058f271 in do_compile () at ../../gcc/toplev.c:2076 #17 toplev::main (this=this@entry=0x7fffffffd7f0, argc=13846, argc@entry=34, argv=0x192f9f0, argv@entry=0x7fffffffd8f8) at ../../gcc/toplev.c:2174 #18 0x000000000058fa6a in main (argc=34, argv=0x7fffffffd8f8) at ../../gcc/main.c:39 More precisely, I used patched compiler just for WPA phase, should also this set-up work? Martin >From gcc-bugs-return-481412-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue Mar 24 12:19:45 2015 Return-Path: <gcc-bugs-return-481412-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org> Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 82980 invoked by alias); 24 Mar 2015 12:19:44 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: <gcc-bugs.gcc.gnu.org> List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/> List-Post: <mailto:gcc-bugs@gcc.gnu.org> List-Help: <mailto:gcc-bugs-help@gcc.gnu.org> Sender: gcc-bugs-owner@gcc.gnu.org Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 82715 invoked by uid 48); 24 Mar 2015 12:19:41 -0000 From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/65519] [5 regression] unable to coalesce ssa_names 2 and 87 which are marked as MUST COALESCE Date: Tue, 24 Mar 2015 12:51:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 5.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: ebotcazou at gcc dot gnu.org X-Bugzilla-Target-Milestone: 5.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: <bug-65519-4-kDvQWeSOHR@http.gcc.gnu.org/bugzilla/> In-Reply-To: <bug-65519-4@http.gcc.gnu.org/bugzilla/> References: <bug-65519-4@http.gcc.gnu.org/bugzilla/> 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-03/txt/msg02556.txt.bz2 Content-length: 159 https://gcc.gnu.org/bugzilla/show_bug.cgi?ide519 --- Comment #15 from Richard Biener <rguenth at gcc dot gnu.org> --- Patch needs adjustments, re-testing. ^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug bootstrap/65537] [5 Regression] --with-build-config=bootstrap-lto fails on CentOS 5.11 2015-03-24 9:26 [Bug bootstrap/65537] New: [5 Regression]: --with-build-config=bootstrap-lto fails on CentOS 5.11 ubizjak at gmail dot com ` (6 preceding siblings ...) 2015-03-24 12:36 ` ubizjak at gmail dot com @ 2015-03-25 8:39 ` ubizjak at gmail dot com 2015-03-25 16:38 ` uros at gcc dot gnu.org 8 siblings, 0 replies; 10+ messages in thread From: ubizjak at gmail dot com @ 2015-03-25 8:39 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65537 Uroš Bizjak <ubizjak at gmail dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |ASSIGNED Last reconfirmed| |2015-03-25 Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com Ever confirmed|0 |1 --- Comment #7 from Uroš Bizjak <ubizjak at gmail dot com> --- Patch at [1]. [1] https://gcc.gnu.org/ml/gcc-patches/2015-03/msg01255.html >From gcc-bugs-return-481542-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Mar 25 07:16:47 2015 Return-Path: <gcc-bugs-return-481542-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org> Delivered-To: listarch-gcc-bugs@gcc.gnu.org Received: (qmail 112664 invoked by alias); 25 Mar 2015 07:16:47 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: <gcc-bugs.gcc.gnu.org> List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/> List-Post: <mailto:gcc-bugs@gcc.gnu.org> List-Help: <mailto:gcc-bugs-help@gcc.gnu.org> Sender: gcc-bugs-owner@gcc.gnu.org Delivered-To: mailing list gcc-bugs@gcc.gnu.org Received: (qmail 112570 invoked by uid 48); 25 Mar 2015 07:16:42 -0000 From: "hubicka at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug ipa/65478] [5 regression] crafty performance regression Date: Wed, 25 Mar 2015 08:40:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: ipa X-Bugzilla-Version: 5.0 X-Bugzilla-Keywords: missed-optimization X-Bugzilla-Severity: normal X-Bugzilla-Who: hubicka 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: bug_status cf_reconfirmed_on everconfirmed Message-ID: <bug-65478-4-ttCZ48uOqG@http.gcc.gnu.org/bugzilla/> In-Reply-To: <bug-65478-4@http.gcc.gnu.org/bugzilla/> References: <bug-65478-4@http.gcc.gnu.org/bugzilla/> 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-03/txt/msg02686.txt.bz2 Content-length: 1413 https://gcc.gnu.org/bugzilla/show_bug.cgi?ide478 Jan Hubicka <hubicka at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Last reconfirmed| |2015-03-25 Ever confirmed|0 |1 --- Comment #10 from Jan Hubicka <hubicka at gcc dot gnu.org> --- Maritn, also note that at that time tere was bug in inliner fixed by:2015-03-20 Jan Hubicka <hubicka@ucw.cz> * ipa-inline.c (can_inline_edge_p): Short circuit if inline_failed already is final. (ipa_inline): Recompute inline_failed codes. * cif-code.def (FUNCTION_NOT_OPTIMIZED, REDEFINED_EXTERN_INLINE, USES_COMDAT_LOCAL, ATTRIBUTE_MISMATCH, UNREACHABLE): Declare as CIF_FINAL_ERROR. so it would be useful to try if the regression still exists on trunk. With the patch our SPEC testers reports improvement http://gcc.opensuse.org/SPEC/CINT/sb-frescobaldi.suse.de-ai-64/186_crafty_recent_big.png While Igor reports even anoter regression on Intel based machine (and slightly different flags) ^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug bootstrap/65537] [5 Regression] --with-build-config=bootstrap-lto fails on CentOS 5.11 2015-03-24 9:26 [Bug bootstrap/65537] New: [5 Regression]: --with-build-config=bootstrap-lto fails on CentOS 5.11 ubizjak at gmail dot com ` (7 preceding siblings ...) 2015-03-25 8:39 ` ubizjak at gmail dot com @ 2015-03-25 16:38 ` uros at gcc dot gnu.org 8 siblings, 0 replies; 10+ messages in thread From: uros at gcc dot gnu.org @ 2015-03-25 16:38 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65537 --- Comment #8 from uros at gcc dot gnu.org --- Author: uros Date: Wed Mar 25 16:01:36 2015 New Revision: 221667 URL: https://gcc.gnu.org/viewcvs?rev=221667&root=gcc&view=rev Log: config/ChangeLog: PR bootstrap/65537 * bootstrap-lto-noplugin.mk: New build configuration. gcc/ChangeLog: PR bootstrap/65537 * doc/install.texi (Building a native compiler): Document new bootstrap-lto-noplugin configuration. Mention that bootstrap-lto configuration assumes that the host supports the linker plugin. Added: trunk/config/bootstrap-lto-noplugin.mk Modified: trunk/config/ChangeLog trunk/gcc/ChangeLog trunk/gcc/doc/install.texi ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2015-03-25 16:02 UTC | newest] Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-03-24 9:26 [Bug bootstrap/65537] New: [5 Regression]: --with-build-config=bootstrap-lto fails on CentOS 5.11 ubizjak at gmail dot com 2015-03-24 9:46 ` [Bug bootstrap/65537] " trippels at gcc dot gnu.org 2015-03-24 9:50 ` ubizjak at gmail dot com 2015-03-24 10:44 ` rguenth at gcc dot gnu.org 2015-03-24 10:45 ` [Bug bootstrap/65537] [5 Regression] " rguenth at gcc dot gnu.org 2015-03-24 11:08 ` trippels at gcc dot gnu.org 2015-03-24 11:44 ` jakub at gcc dot gnu.org 2015-03-24 12:36 ` ubizjak at gmail dot com 2015-03-25 8:39 ` ubizjak at gmail dot com 2015-03-25 16:38 ` uros at gcc dot gnu.org
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).