Re: lang.opts help

[Philip Herron <redbrain@gcc.gnu.org>]

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.