Ralf Wildenhues writes:
> I casually looked at libgo/{Makefile.am,configure.ac}.
Thanks for the review.
> You don't need to list .c files in the BUILT_SOURCES variable if they
> are also listed in some _SOURCES variable (and are not
> undocumented prerequisites for other targets). make will k
Hello,
* Joseph S. Myers wrote on Sat, Nov 06, 2010 at 11:41:17PM CET:
> On Wed, 3 Nov 2010, Ian Lance Taylor wrote:
>
> > There is also the libgo directory. The contents of libgo/go are a copy
> > of the standard Go library and I don't think a review of that would be
> > useful. But it would b
On Wed, 3 Nov 2010, Ian Lance Taylor wrote:
> "Joseph S. Myers" writes:
>
> > I think new front ends should be reviewed for general style, coding
> > conventions, use of deprecated interfaces, unportabilities etc., just as
> > new back ends should be reviewed.
>
> Would anybody care to volunt
> 2010-10-28 Ian Lance Taylor
>
> * lto-objfile.c: New file.
> * lto-elf.c: Remove file.
This has removed the support for compatible architectures present in lto-elf.c
and hasn't added any replacement in libiberty, so a bunch of LTO tests fail
again on 32-bit SPARC/Solaris.
The o
"Joseph S. Myers" writes:
> I think new front ends should be reviewed for general style, coding
> conventions, use of deprecated interfaces, unportabilities etc., just as
> new back ends should be reviewed.
Would anybody care to volunteer to review the Go frontend on these
grounds? The code c
On Tue, 2 Nov 2010, Ian Lance Taylor wrote:
> > I presume you will be posting the front end and other changes for review
> > (or, I suppose, given the size of the changes, explicitly stating that you
> > propose for review the diffs between particular revisions of trunk and a
> > branch given b
"Joseph S. Myers" writes:
> 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
>>
On 11/02/2010 11:50 AM, Paolo Bonzini wrote:
On 11/01/2010 07:17 PM, Ian Lance Taylor wrote:
Tom Tromey writes:
Ian> This patch puts the code in libiberty, but it could equally well
go in
Ian> gcc. Anybody want to make an argument one way or another?
Ian> +extern const char *
Ian> +objfile_at
On 11/01/2010 07:17 PM, Ian Lance Taylor wrote:
Tom Tromey writes:
"Ian" == Ian Lance Taylor writes:
Ian> This patch puts the code in libiberty, but it could equally well go in
Ian> gcc. Anybody want to make an argument one way or another?
Ian> +extern const char *
Ian> +objfile_attri
Tom Tromey writes:
>> "Ian" == Ian Lance Taylor writes:
>
> Ian> This patch puts the code in libiberty, but it could equally well go in
> Ian> gcc. Anybody want to make an argument one way or another?
>
> Ian> +extern const char *
> Ian> +objfile_attributes_compare (objfile_attributes *attr
> "Ian" == Ian Lance Taylor writes:
Ian> This patch puts the code in libiberty, but it could equally well go in
Ian> gcc. Anybody want to make an argument one way or another?
Ian> +extern const char *
Ian> +objfile_attributes_compare (objfile_attributes *attrs1,
GDB already uses the name "
Florian Weimer writes:
> * Ian Lance Taylor:
>
>> 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 .
>
> How general is the garbage collector and its support infrastructure in
> the compiler? AFAICS, it
* Ian Lance Taylor:
> 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 .
How general is the garbage collector and its support infrastructure in
the compiler? AFAICS, it's precise, unlike the Boehm/Dehmer
Dave Korn writes:
> Attached are the revised version of the file, and a diff to show what I
> changed. With this version, all the tests in gcc.dg/lto/lto.exp pass as
> before (i.e. there are still a couple of pre-existing FAILs that aren't
> affected).
Excellent, thanks. I have incorporated
Dave Korn writes:
> On 30/10/2010 19:24, Richard Henderson wrote:
>> On 10/30/2010 11:37 AM, Dave Korn wrote:
Uh, really? I thought there were like a half-dozen lto sections...
>>> Which we iterate over just once, and record them all in a hash table from
>>> the per-section callback, unle
"H.J. Lu" writes:
> Will put
>
> if [ Go is enabled ]; then
> boot_language=yes
> fi
>
> in cp/config-lang.in work?
Probably, but why should I change cp/config-lang.in if I want to support
Go? Everything required to support Go should, as much as possible, be
in the Go frontend.
Ian
On 30/10/2010 19:24, Richard Henderson wrote:
> On 10/30/2010 11:37 AM, Dave Korn wrote:
>>> Uh, really? I thought there were like a half-dozen lto sections...
>> Which we iterate over just once, and record them all in a hash table from
>> the per-section callback, unless I've missed something.
On 10/30/2010 11:37 AM, Dave Korn wrote:
>> Uh, really? I thought there were like a half-dozen lto sections...
>
> Which we iterate over just once, and record them all in a hash table from
> the per-section callback, unless I've missed something.
Oh, right. Nevermind then.
r~
On 30/10/2010 18:57, Richard Henderson wrote:
> On 10/30/2010 01:16 AM, Dave Korn wrote:
>>> Do we really want to keep re-reading section data for every section
>>> lookup we do? Can't we do this in objfile_open_read?
>> It should only be necessary to do one section lookup per object file
>> an
On 10/30/2010 01:16 AM, Dave Korn wrote:
>> Do we really want to keep re-reading section data for every section
>> lookup we do? Can't we do this in objfile_open_read?
>
> It should only be necessary to do one section lookup per object file anyway.
> Keep extra data hanging around in memory in
On 30/10/2010 11:44, Dave Korn wrote:
> On 29/10/2010 02:31, Ian Lance Taylor wrote:
>
>> This implements an object file reader/writer which does everything
>> required by LTO and gccgo. The ELF code works. I have not tested the
>> Mach-O and COFF code at all beyond compiling it; I hope that som
On 29/10/2010 02:31, Ian Lance Taylor wrote:
> * objfile-coff.c: New file.
A few bugs have cropped up:
> + if (namebuf[0] == '/')
> + {
> + size_t strindex;
> + char *end;
> +
> + strindex = strtol (namebuf, &end, 10);
Needs to be strtol (namebuf + 1,
On 29/10/2010 02:31, Ian Lance Taylor wrote:
> This implements an object file reader/writer which does everything
> required by LTO and gccgo. The ELF code works. I have not tested the
> Mach-O and COFF code at all beyond compiling it; I hope that somebody
> else can test those targets and fix t
On 10/30/2010 05:30 AM, H.J. Lu wrote:
Will put
if [ Go is enabled ]; then
boot_language=yes
fi
in cp/config-lang.in work?
It's a bit backwards, no?
Paolo
On 30/10/2010 01:23, Richard Henderson wrote:
>> + if (!objfile_internal_read (objfile->descriptor,
>> + objfile->offset + eor->shoff + shdr_size,
>> + shdrs,
>> + shdr_size * (shnum - 1),
>> + &er
On Fri, Oct 29, 2010 at 4:39 PM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>> On Fri, Oct 29, 2010 at 4:15 PM, Ian Lance Taylor wrote:
>>> Paolo Bonzini writes:
>>>
On 10/24/2010 07:40 AM, Ian Lance Taylor wrote:
> configure.ac
> Add libgo. If building Go, build C++ as a bo
> +extern objfile_read *
> +objfile_open_read (int descriptor, off_t offset, const char *segment_name,
> +const char **errmsg, int *err);
...
> +extern objfile_write *
> +objfile_start_write (objfile_attributes *ATTRS, const char *segment_name,
> + const char **errm
"H.J. Lu" writes:
> On Fri, Oct 29, 2010 at 4:15 PM, Ian Lance Taylor wrote:
>> Paolo Bonzini writes:
>>
>>> 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
On Fri, Oct 29, 2010 at 4:15 PM, Ian Lance Taylor wrote:
> Paolo Bonzini writes:
>
>> 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?
>
> I hav
Paolo Bonzini writes:
> 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?
I have now done this on the gccgo branch. If language X's
config-lang.in
Jack Howarth writes:
>Is split stack support unique to the go compiler or might it eventually
> be leveraged in the other compilers as well? We could submit a radar for
> the addition of split stack support for the linker in Xcode 4.0 or later
> but it would helpful if the eventual usage was
On 10/28/2010 6:31 PM, Ian Lance Taylor wrote:
> This patch requires approval from the LTO maintainers. I don't need
> approval for the libiberty changes (if the code stays in libiberty) but
> of course I would appreciate it if somebody could look it over. I think
> the configure and Makefile ch
On Fri, Oct 29, 2010 at 06:49:51AM -0700, Ian Lance Taylor wrote:
> Jack Howarth writes:
>
> >Doesn't the go compiler require functional split stack support? Mike
> > Stump
> > left me with the impression that split stack support would require
> > additional
> > linker support on darwin.
>
Jack Howarth writes:
>Doesn't the go compiler require functional split stack support? Mike Stump
> left me with the impression that split stack support would require additional
> linker support on darwin.
The Go compiler can work without split stack support. The effect is
that you are limit
On 29/10/2010 14:18, Jack Howarth wrote:
> On Fri, Oct 29, 2010 at 09:56:02AM +0100, Dave Korn wrote:
>> On 29/10/2010 02:31, Ian Lance Taylor wrote:
>>> Dave Korn >>
What would be even nicer would be if we could share the same code-reader
interface between lto and go (and the lto-plugi
On 29/10/2010 14:31, Richard Guenther wrote:
> On Fri, Oct 29, 2010 at 3:31 AM, Ian Lance Taylor wrote:
>> This patch requires approval from the LTO maintainers. I don't need
>> approval for the libiberty changes (if the code stays in libiberty) but
>> of course I would appreciate it if somebody
On Fri, Oct 29, 2010 at 3:31 AM, Ian Lance Taylor wrote:
> Dave Korn writes:
>
>> What would be even nicer would be if we could share the same code-reader
>> interface between lto and go (and the lto-plugin), thereby getting object
>> format independence equally everywhere for no extra cost.
>
On Fri, Oct 29, 2010 at 09:56:02AM +0100, Dave Korn wrote:
> On 29/10/2010 02:31, Ian Lance Taylor wrote:
> > Dave Korn >
> >> What would be even nicer would be if we could share the same code-reader
> >> interface between lto and go (and the lto-plugin), thereby getting object
> >> format inde
On 29 Oct 2010, at 09:56, Dave Korn wrote:
This implements an object file reader/writer which does everything
required by LTO and gccgo. The ELF code works. I have not tested
the
Mach-O and COFF code at all beyond compiling it; I hope that somebody
else can test those targets and fix them.
On 29/10/2010 02:31, Ian Lance Taylor wrote:
> Dave Korn
>> What would be even nicer would be if we could share the same code-reader
>> interface between lto and go (and the lto-plugin), thereby getting object
>> format independence equally everywhere for no extra cost.
>
> How about this?
On Tue, Oct 26, 2010 at 11:51:20AM -0400, Mark Mitchell wrote:
> On 10/26/2010 10:41 AM, Joseph S. Myers wrote:
>
> > Well, slow on hosts where process creation is slow (just like the separate
> > gcc/cc1/as/collect2/ld/lto-wrapper/... processes). The separate process
> > design was probably ba
Mark Mitchell writes:
> A lot of this is also historical; gcc/cc1/as/ld mirror typical UNIX
> compilers of the era at which GCC was built. collect2 was presumably
> necessary because of dependence on proprietary ld; if we could assume
> GNU ld (or GOLD) everywhere, we could fold that functionali
On 10/26/2010 10:41 AM, Joseph S. Myers wrote:
> Well, slow on hosts where process creation is slow (just like the separate
> gcc/cc1/as/collect2/ld/lto-wrapper/... processes). The separate process
> design was probably based on process creation being fast
A lot of this is also historical; gcc
On Mon, 25 Oct 2010, Mark Mitchell wrote:
> On 10/25/2010 10:34 PM, Frank Ch. Eigler wrote:
>
> > By the way, is there some necessity in accomplishing this by means of
> > a linked library, as opposed to via a spawned objcopy process?
(elfcpp isn't a *linked* library; it's a C++ template library
On 10/25/2010 10:39 PM, Frank Ch. Eigler wrote:
> It would seem to moot the present discussion about competing elf
> consumer libraries. "none of the above" is a possible answer.
True. It seems that LTO and Go need a very simple interface; presumably
we can abstract that in the compiler and the
Hi -
> > By the way, is there some necessity in accomplishing this by means of
> > a linked library, as opposed to via a spawned objcopy process?
> Probably none in theory, but it certainly seems messy and likely to
> be slow in practice.
Yes, maybe.
> Is there a reason that this would be desir
On 10/25/2010 10:34 PM, Frank Ch. Eigler wrote:
> By the way, is there some necessity in accomplishing this by means of
> a linked library, as opposed to via a spawned objcopy process?
Probably none in theory, but it certainly seems messy and likely to be
slow in practice. Is there a reason that
Dave Korn writes:
> [...] From Ian's description, gccgo has the exact same requirements
> as LTO: be able to parse an object file, get a list of sections, and
> get raw binary access to the data contained within a named section.
> This is a problem which we already have solved. (And indeed LTO'
On 10/25/2010 10:07 PM, Dave Korn wrote:
> - integrate gccgo, with elfcpp
> - then common out the file-reading stuff from gcc/lto/ up to gcc/ so that all
> the FEs can share it
> - then convert it to use elfcpp (with a bit of file I/O added) and stop using
> libelf altogether
> - then switch gccgo
On 25/10/2010 23:49, Mark Mitchell wrote:
> On 10/25/2010 7:01 PM, Dave Korn wrote:
>
>> What would be even nicer would be if we could share the same code-reader
>> interface between lto and go (and the lto-plugin), thereby getting object
>> format independence equally everywhere for no extra co
On 10/25/2010 7:01 PM, Dave Korn wrote:
> What would be even nicer would be if we could share the same code-reader
> interface between lto and go (and the lto-plugin), thereby getting object
> format independence equally everywhere for no extra cost.
>
> That could be orthogonal to plugging e
On 25/10/2010 19:43, Andi Kleen wrote:
> Andrew Pinski writes:
>
>> On Mon, Oct 25, 2010 at 11:15 AM, Ian Lance Taylor wrote:
>>> At least, that is how I see it.
>> Why not require libelf just like for LTO? That seems like a time to
>> reduce what we depend on. For an example if we compile wit
Andrew Pinski writes:
> On Mon, Oct 25, 2010 at 11:15 AM, Ian Lance Taylor wrote:
>> At least, that is how I see it.
>
> Why not require libelf just like for LTO? That seems like a time to
> reduce what we depend on. For an example if we compile with lto and
> go, GCC will use two different el
On Mon, Oct 25, 2010 at 11:15 AM, Ian Lance Taylor wrote:
> At least, that is how I see it.
Why not require libelf just like for LTO? That seems like a time to
reduce what we depend on. For an example if we compile with lto and
go, GCC will use two different elf libraries. This seems dumb real
Mark Mitchell writes:
> On 10/24/2010 10:52 PM, Ian Lance Taylor wrote:
>
>> It's hard for me to believe that BFD is the correct answer. It's poorly
>> designed for the kinds of things the compiler needs to do. Any program
>> which links against BFD effectively links in the GNU linker.
>
> It s
On 10/24/2010 10:52 PM, Ian Lance Taylor wrote:
> It's hard for me to believe that BFD is the correct answer. It's poorly
> designed for the kinds of things the compiler needs to do. Any program
> which links against BFD effectively links in the GNU linker.
It sounded from your mail like all th
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
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
"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
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
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
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
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, 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
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
65 matches
Mail list logo
