This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Discussion about merging Go frontend

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/
>   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 
<>, 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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]