[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: freeze exception for gcc-4.5 (i386, amd64 only)



On Mon, Aug 23, 2010 at 02:05:25PM +0200, Matthias Klose wrote:
> On 23.08.2010 13:30, Pierre Habouzit wrote:
> >On Mon, Aug 23, 2010 at 01:21:04PM +0200, Pierre Habouzit wrote:
> >>On Mon, Aug 23, 2010 at 04:05:32AM +0200, Matthias Klose wrote:
> >>>On 21.08.2010 14:56, Julien Cristau wrote:
> >>>>On Fri, Aug 20, 2010 at 19:33:12 +0200, Arthur Loiret wrote:
> >>>>
> >>>>>Now, to be clear, what nice things would gcc-4.5 bring to our users?
> >>>>>There is a complete list here [0], but those ones are, in my opinion,
> >>>>>very nice:
> >>>>>  - The new link time optimiser.
> >>>>>  - Improved C++0x support.
> >>>>>  - Plugins support.
> >>>>>
> >>>>My understanding is that lto in 4.5 is not quite there yet.  Not that
> >>>>I've tried it or anything.
> >>>
> >>>I don't share your understanding. I tried it for some builds.
> >>
> >>I've tried it on the work repository, and lto ICEs the compiler. Plus I
> >>get 2 other independant ICEs that I've not had time to reduce (hence the
> >>lack of bug report yet).
> >
> >>Though this happens with the gcc-4.5 in unstable, I've not tried with
> >>the one from experimental yet.
> >
> >Okay, it's not strictly speaking an ICE but I get, even with the one from
> >experimental:
> >
> >qdb/qoutput-c.c:424:1: sorry, unimplemented: gimple bytecode streams do not support the optimization attribute
> 
> are the optimization flags both passed to the compiler and the linker?

Yes, and this happens on the compilation phase anyway, before the link
time. I'll try to reduce it, but I've not had the time yet, and it's
code from work that I definitely cannot give you access to.

> >It's just that LTO isn't that a compelling reason, it's not 100%
> >production ready. The plugin infrastructure is though. But you're citing
> >dragonegg, and last time I checked, you had to patch gcc to export one
> >more symbol. If you haven't applied that patch (if it's still required)
> >your argument is moot. But I agree the plugin infrastructure *is* a
> >compelling reason.
> 
> the dragonegg package did never need a patch for gcc. It's still not needed.

Well, not so long time ago
http://llvm.org/svn/llvm-project/dragonegg/trunk/gcc-patches/ wasn't
empty ;)

So that's good news.
-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org


Reply to: