The Go frontend was approved for inclusion with gcc by the steering
committee a while back: http://gcc.gnu.org/ml/gcc/2010-01/msg00500.html .
Assuming it is OK with the release managers, I would like to get it into
the gcc 4.6 release. I have been running behind my intended schedule,
for which I
On Sat, 23 Oct 2010, Ian Lance Taylor wrote:
> affect other languages. The only thing I hope to clean up further
> before the merge is additional separation between the Go frontend proper
> and the gcc-specific interface. I'm not going to have time to do the
> full planned separation, which I wi
On 24/10/2010 06:40, Ian Lance Taylor wrote:
> There are three new source code directories: gcc/go, libgo, and elfcpp.
> The last is currently part of the src repository, where it is used by
> gold. I propose moving the master copy of elfcpp to gcc, and handling
> it like libiberty.
What about
On Sat, Oct 23, 2010 at 10:40 PM, Ian Lance Taylor wrote:
> The Go frontend was approved for inclusion with gcc by the steering
> committee a while back: http://gcc.gnu.org/ml/gcc/2010-01/msg00500.html .
>
> Assuming it is OK with the release managers, I would like to get it into
> the gcc 4.6 rel
Snapshot gcc-4.3-20101024 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20101024/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On 10/24/2010 07:40 AM, Ian Lance Taylor wrote:
configure.ac
Add libgo. If building Go, build C++ as a boot language.
Can you generalize this using something in gcc/go/config-lang.in?
Paolo
Dave Korn writes:
> On 24/10/2010 06:40, Ian Lance Taylor wrote:
>
>> There are three new source code directories: gcc/go, libgo, and elfcpp.
>> The last is currently part of the src repository, where it is used by
>> gold. I propose moving the master copy of elfcpp to gcc, and handling
>> it li
"H.J. Lu" writes:
> Does Go depend on split stack?
Yes.
> There are at least 2 split stack bugs
> open for x86 target.
Yes, I saw those but I have not had time to look at them. I will.
Ian
Why can't gccgo handle this like gnu objective-c runtime handles this?
Why does it need to be designed such it is in a specific section
instead of registering at runtime? Seems like this a bad design of
registering modules really.
On Oct 24, 2010, at 7:52 PM, Ian Lance Taylor wrote:
Dav
Andrew Pinski writes:
> Why can't gccgo handle this like gnu objective-c runtime handles this?
> Why does it need to be designed such it is in a specific section
> instead of registering at runtime? Seems like this a bad design of
> registering modules really.
This is data generated by the comp
10 matches
Mail list logo
