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). > gcc/opts.c > gcc/toplev.c > gcc/debug.h > gcc/flag-types.h > gcc/c-family/c-lex.c > gcc/Makefile.in > 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 <http://gcc.gnu.org/ml/gcc/2010-01/msg00504.html>. -- Joseph S. Myers jos...@codesourcery.com
