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.
