* RE: lang.opts help
@ 2013-06-29 13:02 Manuel López-Ibáñez
[not found] ` <CAEvRbepEE3MVPhwtYSHfw25YHqpZpE=v81yNBJCikBiym6knuQ@mail.gmail.com>
0 siblings, 1 reply; 5+ messages in thread
From: Manuel López-Ibáñez @ 2013-06-29 13:02 UTC (permalink / raw)
To: Philip Herron, gcc-help
> 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.
^ permalink raw reply [flat|nested] 5+ messages in thread
[parent not found: <CAEvRbepEE3MVPhwtYSHfw25YHqpZpE=v81yNBJCikBiym6knuQ@mail.gmail.com>]
[parent not found: <CAESRpQB6xeyd1idRyf7UXY+Sroy=EcvAfOZ9KCVVD+Hm_xKQbg@mail.gmail.com>]
* Re: lang.opts help [not found] ` <CAESRpQB6xeyd1idRyf7UXY+Sroy=EcvAfOZ9KCVVD+Hm_xKQbg@mail.gmail.com> @ 2013-07-01 9:14 ` Philip Herron 2013-07-01 10:08 ` Manuel López-Ibáñez 0 siblings, 1 reply; 5+ messages in thread From: Philip Herron @ 2013-07-01 9:14 UTC (permalink / raw) To: Manuel López-Ibáñez; +Cc: gcc-help 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@gmail.com> 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@gcc.gnu.org> 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@gmail.com> 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: lang.opts help 2013-07-01 9:14 ` Philip Herron @ 2013-07-01 10:08 ` Manuel López-Ibáñez 2013-07-01 13:43 ` Philip Herron 0 siblings, 1 reply; 5+ messages in thread From: Manuel López-Ibáñez @ 2013-07-01 10:08 UTC (permalink / raw) To: Philip Herron; +Cc: gcc-help 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@pfeifer.com and/or joseph@codesourcery.com, 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@gcc.gnu.org> 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@gmail.com> 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@gcc.gnu.org> 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@gmail.com> 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: lang.opts help 2013-07-01 10:08 ` Manuel López-Ibáñez @ 2013-07-01 13:43 ` Philip Herron 0 siblings, 0 replies; 5+ messages in thread From: Philip Herron @ 2013-07-01 13:43 UTC (permalink / raw) To: Manuel López-Ibáñez; +Cc: gcc-help 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@gmail.com> 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@pfeifer.com and/or joseph@codesourcery.com, 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@gcc.gnu.org> 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@gmail.com> 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@gcc.gnu.org> 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@gmail.com> 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. ^ permalink raw reply [flat|nested] 5+ messages in thread
* lang.opts help @ 2013-06-28 20:01 Philip Herron 0 siblings, 0 replies; 5+ messages in thread From: Philip Herron @ 2013-06-28 20:01 UTC (permalink / raw) To: GCC Hey all 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 ‘-fpy-dump-dot’ is valid for Python but not for [enabled by default] gpy1: warning: command line option ‘-fpy-gen-main’ is valid for Python but not for [enabled by default] gpy1: warning: command line option ‘-L/usr/local/lib/gcc/x86_64-apple-darwin12.3.0/4.8.0’ is valid for Go/Python but not for [enabled by default] gpy1: warning: command line option ‘-L/usr/local/lib/gcc/x86_64-apple-darwin12.3.0/4.8.0/../../..’ is valid for Go/Python but not for [enabled by default] And my lang.opts is: Language Python I Python Joined Separate ; Documented in c.opt L Python Joined Separate ; Not documented fpy-gen-main Python Var(GPY_OPT_gen_main) Init(0) -fpy-gen-main Dump out main hook such that compiled module is main fpy-dump-dot Python Var(GPY_OPT_dump_dot) Init(0) -fpy-dump-dot Makes front-end dump dotIL Types and AST o Python Joined Separate ; Documented in common.opt Thanks --Phil ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2013-07-01 13:43 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-06-29 13:02 lang.opts help Manuel López-Ibáñez [not found] ` <CAEvRbepEE3MVPhwtYSHfw25YHqpZpE=v81yNBJCikBiym6knuQ@mail.gmail.com> [not found] ` <CAESRpQB6xeyd1idRyf7UXY+Sroy=EcvAfOZ9KCVVD+Hm_xKQbg@mail.gmail.com> 2013-07-01 9:14 ` Philip Herron 2013-07-01 10:08 ` Manuel López-Ibáñez 2013-07-01 13:43 ` Philip Herron -- strict thread matches above, loose matches on Subject: below -- 2013-06-28 20:01 Philip Herron
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).