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.
