Re: gccgo: A gcc frontend for Go, a new programming language

Basile STARYNKEVITCH writes: > BTW, I understood perhaps wrongly that Ian Taylor seems to believe > that gccgo has not much future, and that most of the software written > in Go (the Google niche language) could be compiled by something which > is not GCC based. I certainly hope that gccgo has a

Re: gccgo: A gcc frontend for Go, a new programming language

Joseph S. Myers wrote: On Wed, 11 Nov 2009, Basile STARYNKEVITCH wrote: * Looking at other niche languages in the past having had a GCC front-end (D, Mercury, perhaps some Modula, or Cobol, or Pascal, ...) it seems that most of them are not accepted in the GCC trunk proper. No, it's not di

Re: gccgo: A gcc frontend for Go, a new programming language

On Wed, 11 Nov 2009, Basile STARYNKEVITCH wrote: > * Looking at other niche languages in the past having had a GCC front-end (D, > Mercury, perhaps some Modula, or Cobol, or Pascal, ...) it seems that most of > them are not accepted in the GCC trunk proper. As far as I understand, neither > gcc-4.

Invitation avant-première

Bonjour, Nous vous proposons de découvrir en avant-première le dernier Disney, « Le drôle de Noël de Scrooge » avec Jim Carrey, De faire avancer la recherche sur les maladies du cerveau, De faire plaisir à vos collaborateurs et à vos clients… Et de découvrir le Rotary ! C'est une initiative d

Re: gccgo: A gcc frontend for Go, a new programming language

Basile STARYNKEVITCH wrote: * Google Go is still a niche language. And I would guess it is targetted to Linux & Unix variants (because I heard that Google does not use Windows on their web-crawling servers, but only Unix variants, mostly Linux). I really feel that a niche language is exactly

Re: gccgo: A gcc frontend for Go, a new programming language

Joe Buck wrote: On Wed, Nov 11, 2009 at 11:26:36AM -0800, Basile STARYNKEVITCH wrote: My feeling is that Google's Go (quite a nice language from the slides I just have read) is almost "canonically" the case for a front-end plugin. I have some major concerns about this suggestion. Isn't this a

Re: gccgo: A gcc frontend for Go, a new programming language

f...@redhat.com (Frank Ch. Eigler) writes: > Ian Lance Taylor writes: > >> [...] Go, a new experimental systems programming language designed >> by a small group at Google. [...] The frontend is written in, yes, >> C++. [...] > > Neat. Are there any plans to have a front-end written in its ow

Re: gccgo: A gcc frontend for Go, a new programming language

On Nov 11, 2009, at 12:43 PM, Joe Buck wrote: They weren't intended as a way of attaching complete new front ends or complete new back ends. That was the thing that RMS feared the most, and he had at least some justification: would we have a C++ compiler or an Objective-C compiler if the

Re: gccgo: A gcc frontend for Go, a new programming language

On Wed, Nov 11, 2009 at 11:26:36AM -0800, Basile STARYNKEVITCH wrote: > My feeling is that Google's Go (quite a nice language from the slides I just > have read) is almost "canonically" the case > for a front-end plugin. I have some major concerns about this suggestion. Isn't this a recipe for

Re: gccgo: A gcc frontend for Go, a new programming language

On Wed, 11 Nov 2009, Basile STARYNKEVITCH wrote: > My feeling is that Google's Go (quite a nice language from the slides I just > have read) is almost "canonically" the case for a front-end plugin. Well, if you really wish to impede host portability in several different ways. * Use of a plugin

RE: Understanding IRA

Ian Bolton wrote: > Vladimir Makarov wrote: > > Ian Bolton wrote: > > > Yesterday, I wrote: > > > > > >> BTW, today I have achieved some good results with existing IRA by > > doing > > >> the following: > > >> > > >> 1) Changed the REG_ALLOC_ORDER so that TOP_CREGS are given out > > before > > >> B

Re: libtool update?

Hello Rainer, * Rainer Emrich wrote on Wed, Nov 11, 2009 at 05:47:13PM CET: > Any news on libtool? Does anybody care to update? Work in progress: Since then, I found a couple of issues, one of which was a bug in the sync and the other I'm

Creating a function dynamically

I am hacking in the gcc code and come to a point where I cant come any further: I want to expand the "-finstrument-functions" to create a dynamic dump function in the background, instead of calling a fixed __cyg_profile_func_enter/exit I.e: if I have f1(int a,int b) { } I would like to create a

Re: gccgo: A gcc frontend for Go, a new programming language

Frank Ch. Eigler wrote: Ian Lance Taylor writes: [...] Go, a new experimental systems programming language designed by a small group at Google. [...] The frontend is written in, yes, C++. [...] Neat. Are there any plans to have a front-end written in its own language (and use the current

RE: Understanding IRA

Vladimir Makarov wrote: > Ian Bolton wrote: > > Yesterday, I wrote: > > > >> BTW, today I have achieved some good results with existing IRA by > doing > >> the following: > >> > >> 1) Changed the REG_ALLOC_ORDER so that TOP_CREGS are given out > before > >> BOTTOM_REGS. My previous hacked version

Re: gccgo: A gcc frontend for Go, a new programming language

Ian Lance Taylor writes: > [...] Go, a new experimental systems programming language designed > by a small group at Google. [...] The frontend is written in, yes, > C++. [...] Neat. Are there any plans to have a front-end written in its own language (and use the current C++ one only for boot

The Linux binutils 2.20.51.0.3 is released

This is the beta release of binutils 2.20.51.0.3 for Linux, which is based on binutils 2009 1109 in CVS on sourceware.org plus various changes. It is purely for Linux. All relevant patches in patches have been applied to the source tree. You can take a look at patches/README to see what have been

Re: Understanding IRA

Ian Bolton wrote: Yesterday, I wrote: BTW, today I have achieved some good results with existing IRA by doing the following: 1) Changed the REG_ALLOC_ORDER so that TOP_CREGS are given out before BOTTOM_REGS. My previous hacked version worked by increasing the priority of those that wanted B

Re: libtool update?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ralf Wildenhues schrieb: > Hello Rainer, > > * Rainer Emrich wrote on Tue, Aug 18, 2009 at 04:08:38PM CEST: >> Are there any plans to update libtool? > > If anybody updates libtool before the Autoconf + Automake update, > I'm probably going to run sc

native x86_64-w64-mingw32 fails to boostrap

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 cause are the generated scripts as and collect-ld in the gcc diretory. After building the stage 1 compiler the configuration of libgcc fails. configure:3019: /home/rainer/tmp/build/./gcc/xgcc - -B/home/rainer/tmp/build/./gcc/ - -L/home/rainer/tmp/inst

Strange optimisation problem - gcc 4.3.2

Hi everyone, I've been looking at adding some code to a performance-critical section of OpenBIOS, and I'm quite confused by how some of the changes I am making are affecting the overall performance. For a benchmark, I am using a recursive fibonacci function to test the effect of any changes

Re: Understanding IRA

On 11/11/09 08:18, Ian Bolton wrote: Good news! I have been able to remove my "total_costs" hack above by instead commenting out the following line from ira_build() in ira-build.c: remove_unnecessary_regions (false); Which is probably an indication of a problem elsewhere. However, it's

RE: Understanding IRA

Yesterday, I wrote: > BTW, today I have achieved some good results with existing IRA by doing > the following: > > 1) Changed the REG_ALLOC_ORDER so that TOP_CREGS are given out before > BOTTOM_REGS. My previous hacked version worked by increasing the > priority of those that wanted BOTTOM_REGS,

Re: [c++]pt.c:most_specialized_class appears to substitute outer args for inner params

On 11/02/09 22:39, Larry Evans wrote: The following code around trunk/gcc/cp/pt.c:15514: 15513 partial_spec_args = INNERMOST_TEMPLATE_ARGS (partial_spec_args); 15514 partial_spec_args = tsubst_template_args 15515 (partial_spec_args, outer_args, tf_none, NULL_TREE); as shown here: