Re: [gfortran] gfortran options and cc1 warnings

[Bernhard Fischer <rep dot nop at aon dot at>]

On Mon, Oct 31, 2005 at 12:51:40AM +0100, FX Coudert wrote:
>This is a patch proposal about PR fortran/18452. In short, to preprocess 
>fortran source files, gfortran calls cc1 with its own options, which 
>gives warnings like:
>
>$ gfortran -fdollar-ok a.F90
>cc1: warning: command line option "-fdollar-ok" is valid for F95 but not 
>for C
>
>A few (two exactly) options were already handled right (-ffixed-form and 
>-ffixed-line-length-n), so I applied the method used for those to all 
>gfortran options. Questions that need adressing are:
>
>  1. can we get that patch in during the short period when 4.1 will 
>unfreeze before branching? it concerns the common code of GCC, and does 
>not fix a regression strictly speaking. But that problem is very 
>annoying to both users (which make compiling very noisy and errors 
>difficult to spot) and developers (preventing libgfortran to be built 
>with -Werror), and working around it while changing only gfortran code 
>would be *ugly*.
>
>  2. what should be the behaviour of "gfortran -fdollar-ok a.f b.c"? is 
>this supposed to be allowed, or not?
>
>  3. if the answer to point 2 is "this isn't allowed", then the 
>testsuite framework should be somehow modified :)
>
>  4.  in the case it is allowed, we then need some very clever way to 
>get options go where they need (C-only options for b.c and Fortran-only 
>options to a.f)
>
>gfortran developers, C front-end maintainers, specs gurus, release 
>managers, please speak up! :)

Neither of them.. I didn't look closely, but when i added
-ffree-line-length- i thought if it would be ok/possible to fill
lang.opts into a new compiler->opts and match against those instead.

That way each option passed in by the user could be matched against all
involved languages -- setting something like compiler->given_args -- and
one could warn about the unknown rest and/or mutual exclusive flags per
language.