From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23447 invoked by alias); 1 Jul 2013 13:43:57 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 23437 invoked by uid 89); 1 Jul 2013 13:43:56 -0000 X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,SPF_PASS,TW_CP,TW_SV autolearn=ham version=3.3.1 Received: from mail-pb0-f42.google.com (HELO mail-pb0-f42.google.com) (209.85.160.42) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Mon, 01 Jul 2013 13:43:55 +0000 Received: by mail-pb0-f42.google.com with SMTP id un1so4879427pbc.15 for ; Mon, 01 Jul 2013 06:43:53 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.68.221.69 with SMTP id qc5mr23919666pbc.60.1372686233793; Mon, 01 Jul 2013 06:43:53 -0700 (PDT) Received: by 10.66.126.9 with HTTP; Mon, 1 Jul 2013 06:43:53 -0700 (PDT) In-Reply-To: References: Date: Mon, 01 Jul 2013 13:43:00 -0000 Message-ID: Subject: Re: lang.opts help From: Philip Herron To: =?ISO-8859-1?Q?Manuel_L=F3pez=2DIb=E1=F1ez?= Cc: "gcc-help@gcc.gnu.org" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2013-07/txt/msg00007.txt.bz2 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=F3pez-Ib=E1=F1ez wro= te: > 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 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 i= t in. >> >> --Phil >> >> On 30 June 2013 22:51, Manuel L=F3pez-Ib=E1=F1ez = 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 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=F3pez-Ib=E1=F1ez 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 =3D91-fpy-dump-dot=3D92 is valid = for Python >>>>>> but not for [enabled by default] >>>>>> gpy1: warning: command line option =3D91-fpy-gen-main=3D92 is valid = for Python >>>>>> but not for [enabled by default] >>>>>> gpy1: warning: command line option >>>>>> =3D91-L/usr/local/lib/gcc/x86_64-apple-darwin12.3.0/4.8.0=3D92 is va= lid for >>>>>> Go/Python but not for [enabled by default] >>>>>> gpy1: warning: command line option >>>>>> =3D91-L/usr/local/lib/gcc/x86_64-apple-darwin12.3.0/4.8.0/../../..= =3D92 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 Fo= rtran: >>>>> >>>>> fortran/f95-lang.c:#define LANG_HOOKS_OPTION_LANG_MASK gfc_option_la= ng_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.