public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: Jan Hubicka <hubicka@ucw.cz>
To: andi-gcc at firstfloor dot org <gcc-bugzilla@gcc.gnu.org>
Cc: gcc-bugs@gcc.gnu.org
Subject: Re: [Bug lto/46905] -flto -fno-lto does not disable lto
Date: Sun, 09 Jan 2011 01:18:00 -0000	[thread overview]
Message-ID: <20110109011016.GI10740@atrey.karlin.mff.cuni.cz> (raw)
In-Reply-To: <bug-46905-4-kno2sAVFIX@http.gcc.gnu.org/bugzilla/>

> slim lto will take some time (next stage1)

I was chatting about this with Diego yesterday and he seems to be fine with the
basic slim LTO patch getting in.  So it seems to me that we might get the slim
LTO patch for 4.6.0 and flip the default for 4.7.0

> i also plan to drop most of the code because with forced plugin
> the elf code in collect2 should not be needed anymore.

I don't know.  Current collect2 code is utterly broken by using wrong symbol
table at first place. With GNU LD getting plugin support the situation got
better, but we still have darwin target where we have no linker support at all.
Apple linker has plugin, so probably one can write plugin glue, but until that
happens, we probably want to keep collect2 path somehow useable.

What I am aware of WRT plugin and LTO is that currently plugin force LTO by
default. I.e.

gcc -flto t.c -c
gcc t.o
will result in WHOPR while producing a.out
I ended up enabling plugin by defualt since that is a must for plugin, but plugin
should be extended to work out whether -flto was passed on the command line (or
be better told by the driver as we don't want to duplicate parsing everywhere)
and when lto is not passed do not claim objects that are not slim.

Honza


  reply	other threads:[~2011-01-09  1:10 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-12 13:50 [Bug lto/46905] New: " andi-gcc at firstfloor dot org
2010-12-12 14:19 ` [Bug lto/46905] " andi-gcc at firstfloor dot org
2010-12-16 14:37 ` rguenth at gcc dot gnu.org
2010-12-19 19:36 ` ak at gcc dot gnu.org
2011-01-08 21:11 ` hubicka at gcc dot gnu.org
2011-01-08 23:35 ` andi-gcc at firstfloor dot org
2011-01-09  1:18   ` Jan Hubicka [this message]
2011-01-09  0:57 ` andi-gcc at firstfloor dot org
2011-01-09  1:28 ` hubicka at ucw dot cz
2011-10-07  5:44 ` andi-gcc at firstfloor dot org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20110109011016.GI10740@atrey.karlin.mff.cuni.cz \
    --to=hubicka@ucw.cz \
    --cc=gcc-bugs@gcc.gnu.org \
    --cc=gcc-bugzilla@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
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).