Yeah i think just taking that wiki page would suit best its probably pretty hard to get suych a huge patch into the gcc internals and its kind of gone to waste that patch so i will stick it there thanks --Phil On 1 July 2013 11:08, Manuel López-Ibáñez <lopezibanez@xxxxxxxxx> wrote: > Adding anything huge is always hard in GCC because there are very very > few people that can review patches, and those people are the same that > do 99% of the work, so they are already saturated. > > The best way to add things to GCC is: > > 1) Find who can approve your patch. In your case, it is probably > gerald@xxxxxxxxxxx and/or joseph@xxxxxxxxxxxxxxxx, but Joseph is > incredibly busy lately with libc, so perhaps C++ maintainers would be > willing to review. > 2) Ask them directly how they will prefer patches (small long series > of patches or larger patch) > 3) Try to get the patches as right as possible from the start > following GCC conventions (look at other docs). > 4) Ping, ping, ping and keep pinging (CCing the maintainers) once > every two weeks until the patches are reviewed. > > As an alternative, you could put your doc (and texi sources) somewhere > (github, a svn branch in gcc.gnu.org) and add a link to it here: > > http://gcc.gnu.org/wiki/WritingANewFrontEnd > > or even better, completely take over that page if you think your > documentation covers most of the stuff there that is not outdated. > > Cheers, > > Manuel. > > > > > On 1 July 2013 11:14, Philip Herron <redbrain@xxxxxxxxxxx> wrote: >> Yeah there is a patch in the list somewhere from ages ago where me and >> Andi Hellmund added huge front-end documentation but it never got >> reviewed. >> >> I think i need to resurrect this again this week and fix it up and get it in. >> >> --Phil >> >> On 30 June 2013 22:51, Manuel López-Ibáñez <lopezibanez@xxxxxxxxx> wrote: >>> Perhaps it should be documented somewhere, but where? To be honest, if >>> I had to implement a GCC FE, I wouldn't even know where to start >>> looking. >>> >>> BTW, don't look to Fortran for a good example of how to handle >>> options. Fortran duplicates the common machinery, which does a lot >>> more than the Fortran implementation. The same applies to diagnostics, >>> don't follow Fortran, use the common machinery. In general, the C++ FE >>> is probably the most modern and the best example to look at. >>> >>> >>> >>> On 30 June 2013 22:17, Philip Herron <redbrain@xxxxxxxxxxx> wrote: >>>> Thanks so much i just never noticed this lang hook just needed to >>>> return the option_lang_mask and now its all fine. >>>> >>>> Thanks >>>> >>>> --Phil >>>> >>>> On 28 June 2013 19:46, Manuel López-Ibáñez <lopezibanez@xxxxxxxxx> wrote: >>>>>> I have been having trouble with my lang.opts i keep getting: >>>>>> >>>>>> hilips-MacBook:gccpy-build redbrain$ gccpy -O0 -fdump-tree-gimple t.py >>>>>> -o t.o -fpy-dump-dot -fpy-gen-main >>>>>> gpy1: warning: command line option =91-fpy-dump-dot=92 is valid for Python >>>>>> but not for [enabled by default] >>>>>> gpy1: warning: command line option =91-fpy-gen-main=92 is valid for Python >>>>>> but not for [enabled by default] >>>>>> gpy1: warning: command line option >>>>>> =91-L/usr/local/lib/gcc/x86_64-apple-darwin12.3.0/4.8.0=92 is valid for >>>>>> Go/Python but not for [enabled by default] >>>>>> gpy1: warning: command line option >>>>>> =91-L/usr/local/lib/gcc/x86_64-apple-darwin12.3.0/4.8.0/../../..=92 is >>>>>> valid for Go/Python but not for [enabled by default] >>>>> >>>>> Does your python_handle_option returns true for recognized options? >>>>> >>>>> When you build, in the build/gcc/ directory there is an options.c >>>>> file. Does it mention Python in lang_names? Do the options have the >>>>> CL_Python flag? >>>>> >>>>> Have you defined a hook that returns the lang_mask for Python? See Fortran: >>>>> >>>>> fortran/f95-lang.c:#define LANG_HOOKS_OPTION_LANG_MASK gfc_option_lang_mask >>>>> >>>>> BTW, you don't need to re-define Common options unless you want to >>>>> completely change their meaning, which normally is a bad idea. >>>>> Normally you can just re-use the results returned by the common >>>>> options machinery for your own purposes. >>>>> >>>>> Cheers, >>>>> >>>>> Manuel.
