This is the mail archive of the
mailing list for the GCC project.
Re: Discussion about merging Go frontend
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Ian Lance Taylor <iant at google dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Sun, 24 Oct 2010 14:58:55 +0000 (UTC)
- Subject: Re: Discussion about merging Go frontend
- References: <email@example.com>
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 will continue to work on, but I hope to
> have the proper framework in place for future work.
Will the front end use its own text domain for i18n of messages, or the
"gcc" domain? Whatever the answer, do you need changes to po/exgettext or
similar to cause all the messages to be properly extracted?
> 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.
How is elfcpp used? Is this front end in some way restricted to ELF
targets, or more functional with them? (In general, to what extent are
the front end and library portable to different targets - how much work,
if any, is needed to get them building and working for a new target
(architecture or OS)? Would the sort of target changes needed be risky
for Stage 3? What about host portability?)
> The following other files are changed:
You don't mention documentation. Does the front end have its own manual?
Whether or not it does, the new-front-end checklist (Front End in
sourcebuild.texi) lists places in the documentation that need updating for
a new front end (install.texi, contrib.texi, frontends.texi,
standards.texi, invoke.texi, sourcebuild.texi - plus web page etc. updates
for merging to trunk).
> Add support for -ggo, used when building runtime library.
Note that all -g* options are also handled in a case statement in
java/jvspec.c, though that might well better be handled through specs, and
I don't know if -ggo makes sense at all for Java.
I think appropriate coding standards documentation for this front end is
needed. Possibly in the form of a description of how the coding standards
differ from the general conventions for C++ in existing parts of GCC at
<http://gcc.gnu.org/wiki/CppConventions>, though those would need merging
into codingconventions.html before being used as a basis for conventions
actually used on GCC trunk.
The front end's langhooks don't seem to have been updated for the
separation of the init_options and init_options_struct hooks.
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 by a particular svn diff command) as indicated in
Joseph S. Myers