[Bug bootstrap/65537] New: [5 Regression]: --with-build-config=bootstrap-lto fails on CentOS 5.11

[Bug bootstrap/65537] New: [5 Regression]: --with-build-config=bootstrap-lto fails on CentOS 5.11

[ubizjak at gmail dot com]

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.

[Bug bootstrap/65537] [5 Regression]: --with-build-config=bootstrap-lto fails on CentOS 5.11

[trippels at gcc dot gnu.org]

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?

[Bug bootstrap/65537] [5 Regression]: --with-build-config=bootstrap-lto fails on CentOS 5.11

[ubizjak at gmail dot com]

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

[Bug bootstrap/65537] [5 Regression]: --with-build-config=bootstrap-lto fails on CentOS 5.11

[rguenth at gcc dot gnu.org]

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?

[Bug bootstrap/65537] [5 Regression] --with-build-config=bootstrap-lto fails on CentOS 5.11

[rguenth at gcc dot gnu.org]

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

[Bug bootstrap/65537] [5 Regression] --with-build-config=bootstrap-lto fails on CentOS 5.11

[trippels at gcc dot gnu.org]

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

[Bug bootstrap/65537] [5 Regression] --with-build-config=bootstrap-lto fails on CentOS 5.11

[jakub at gcc dot gnu.org]

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.

[Bug bootstrap/65537] [5 Regression] --with-build-config=bootstrap-lto fails on CentOS 5.11

[ubizjak at gmail dot com]

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.

[Bug bootstrap/65537] [5 Regression] --with-build-config=bootstrap-lto fails on CentOS 5.11

[ubizjak at gmail dot com]

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)

[Bug bootstrap/65537] [5 Regression] --with-build-config=bootstrap-lto fails on CentOS 5.11

[uros at gcc dot gnu.org]

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