On Tue, 18 Jun 2013, Andi Kleen wrote:
> On Tue, Jun 18, 2013 at 08:04:15PM +0200, Andi Kleen wrote:
> > > Just confirmed with the small build. It does. Running the large build
> > > now.
> >
> > Large build worked too.
>
> Also it seems to be drastically faster. I haven't done a proper
> meas
On Tue, Jun 18, 2013 at 08:04:15PM +0200, Andi Kleen wrote:
> > Just confirmed with the small build. It does. Running the large build
> > now.
>
> Large build worked too.
Also it seems to be drastically faster. I haven't done a proper
measurement run, but the initial run was 58% faster than 4.8
> Just confirmed with the small build. It does. Running the large build
> now.
Large build worked too.
>
> Please check in.
> That suggests
>
> Index: gcc/expr.c
> ===
> --- gcc/expr.c (revision 200164)
> +++ gcc/expr.c (working copy)
> @@ -9353,7 +9353,7 @@ expand_expr_real_1 (tree exp, rtx target
>/* Variables inherited from containing function
> > make oldconfig
> > make CC=gcc LD=ld-from-linux-binutils AR=gcc-ar -j ..
>
> Ok, it doesn't use LTO for me, not even with adding CFLAGS="-O2 -flto"
> here.
Can you send me a build log with V=1 ?
There are some checks for the environment at the beginning, maybe they fail.
-Andi
--
a...@li
On Mon, 17 Jun 2013, Andi Kleen wrote:
> Richard Biener writes:
>
> > Andi Kleen wrote:
> >
> >>
> >>Current trunk cannot build LTO kernels now, with your patch,
> >>as reported earlier.
> >>
> >>Please fix ASAP. I'm surprised that you checked in a patchkit
> >>with such serious reported probl
On Mon, 17 Jun 2013, Andi Kleen wrote:
>
> Current trunk cannot build LTO kernels now, with your patch,
> as reported earlier.
>
> Please fix ASAP. I'm surprised that you checked in a patchkit
> with such serious reported problems.
>
> -Andi
>
>
> backup/lsrc/git/linux-lto-2.6/lib/decompress
Hello,
I tried to compile LTO kernel with latest gcc, applied patch by
Jan http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57334#c6:
lto1: internal compiler error: in lto_symtab_prevailing_decl, at
lto-symtab.c:644
0x783c63 lto_symtab_prevailing_decl(tree_node*)
../../gcc/lto-symtab.c:644
0x50afe4
Andi Kleen wrote:
>
>Current trunk cannot build LTO kernels now, with your patch,
>as reported earlier.
>
>Please fix ASAP. I'm surprised that you checked in a patchkit
>with such serious reported problems.
Instructions for reproducing this issue appreciated. I've never built lto
kernels.
Ric
Current trunk cannot build LTO kernels now, with your patch,
as reported earlier.
Please fix ASAP. I'm surprised that you checked in a patchkit
with such serious reported problems.
-Andi
backup/lsrc/git/linux-lto-2.6/lib/decompress_unlzo.c: In function 'unlzo':
/backup/lsrc/git/linux-lto-2.6/
On Mon, Jun 17, 2013 at 10:12:41AM +0200, Jan Hubicka wrote:
> > > CPU: AMD64 family10, speed 2100 MHz (estimated)
> > > Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a
> > > unit mask of 0x00 (No unit mask) count 75
> > > samples %app name symbol
> > CPU: AMD64 family10, speed 2100 MHz (estimated)
> > Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a unit
> > mask of 0x00 (No unit mask) count 75
> > samples %app name symbol name
> > 4504711.7420 lto1 inflate_fast
>
On Sat, 15 Jun 2013, Jan Hubicka wrote:
> >
> > I've managed to fix nearly all reported missed merged types for cc1.
> > Remaining are those we'll never be able to merge (merging would
> > change the SCC shape) and those that eventually end up refering
> > to a TYPE_STUB_DECL with a make_anon_nam
>
> Patch didn't survive a kernel lto build. LTO test cases are tricky as usual,
> but I can give you a objdir
> or core file if you want.
I was looking into this ICE and it is DECL_CONTEXT being wrong. There is
another PR about the same, so i will try to debug it and figure out why.
Otherwise
>
> I've managed to fix nearly all reported missed merged types for cc1.
> Remaining are those we'll never be able to merge (merging would
> change the SCC shape) and those that eventually end up refering
> to a TYPE_STUB_DECL with a make_anon_name () IDENTIFIER_NODE.
> For the latter we should fi
Patch didn't survive a kernel lto build. LTO test cases are tricky as usual,
but I can give you a objdir
or core file if you want.
-Andi
/backup/lsrc/git/linux-lto-2.6/lib/decompress_unlzo.c:79:8: internal compiler
error: in expand_expr_real_1, at expr.c:9361
parse += 7;
^
0x5e87d5 e
16 matches
Mail list logo
