RE: lang.opts help

RE: lang.opts help

[Manuel López-Ibáñez]

> 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.

Re: lang.opts help

[Philip Herron]

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.

Re: lang.opts help

[Manuel López-Ibáñez]

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.

Re: lang.opts help

[Philip Herron]

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.

lang.opts help

[Philip Herron]

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