From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19878 invoked by alias); 10 Apr 2010 16:20:50 -0000 Received: (qmail 19790 invoked by uid 48); 10 Apr 2010 16:20:28 -0000 Date: Sat, 10 Apr 2010 16:20:00 -0000 Message-ID: <20100410162028.19789.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug lto/42776] LTO doesn't work on non-ELF platforms. In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "davek at gcc dot gnu dot org" 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 X-SW-Source: 2010-04/txt/msg01039.txt.bz2 ------- Comment #31 from davek at gcc dot gnu dot org 2010-04-10 16:20 ------- (In reply to comment #30) > there is something odd. > with lto: > Time: 674.484 sec (11 m 14 s) > without: > Time: 419.938 sec (6 m 59 s) > a lot slower using lto? Is it possible you're just seeing the effects of file caching? After the first scan, you'd expect the second one to be faster. Could you run them each say three or five times in a row and see if it's just a side-effect of this? Otherwise, it is of course certainly possible that there's some kind of bug in LTO that leads to inadvertent pessimisation of code; it's a new feature after all. But it's surprising that it would show to such an extent in an application like this, which I would have expected to be pretty much completely I/O bound. Thanks for doing all this testing, by the way; I haven't had time to try it out on any big projects yet. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42776