Use -cpp= for Fortran -cpp option passed to f951

I think my option handling patch series is now quite close to being
able to make the driver share the option processing machinery of the
core compilers.

There are of course options accepted by the driver but not the core
compilers, or by the core compilers but not the driver.  This is not
in itself a problem - the machinery already handles options known to
one front end but not another, and this is a similar case.  Indeed,
almost all options for any of the core compilers should be accepted by
the driver (and passed down via specs), while if a driver-only option
is passed to cc1 it seems quite appropriate to warn or error that it
is driver-only, like the existing warnings for other-front-end
options.

More of a problem, however, is options that are incompatible between
the driver and the core compilers regarding whether they take
arguments; adding support for such variations in option semantics
seems like an undesirable complication, given that the interface to
the core compilers is a purely internal matter that we can change for
implementation convenience.

Thus, I have reviewed all 71 options files for options with such
incompatibilities.  Several oddities have come to light that are clear
bugs that I will fix in due course, plus two clear incompatibilities
that need addressing before the option-processing machinery can be
shared:

* The Fortran -cpp option takes no argument as an option to the
  driver, but takes an argument as an option to f951.

* common.opt unconditionally supports the -G option (-Gn and -G n,
  small data size).  This option is passed down by specs on some but
  not all targets, and SWITCH_TAKES_ARG controls whether the driver
  thinks -G has an argument on a given target.  On some targets not
  passing it to cc1, there is instead a -G option with no argument
  that specs pass to the *linker*, which is of course incompatible
  with the driver knowing about the -G option from common.opt on such
  systems.

This patch fixes the first of these issues, by changing the internal
-cpp option to -cpp= taking a joined argument.  As a side-effect, the
Negative markers on -cpp (public option to the driver, no argument)
and -nocpp will now be effective (prune_options ignores all options
marked Joined, so the Negative markers would not previously have done
anything).

Bootstrapped with no regressions on x86_64-unknown-linux-gnu.  OK to
commit?

2010-07-28  Joseph Myers  <joseph@codesourcery.com>

	* lang.opt (cpp): Remove Joined and Separate markers.
	(cpp=): New internal option.
	* lang-specs.h (F951_CPP_OPTIONS): Generate -cpp= option.
	* cpp.c (gfc_cpp_handle_option): Handle OPT_cpp_ instead of
	OPT_cpp.

Joseph S. Myers wrote:
> This patch fixes the first of these issues, by changing the internal
> -cpp option to -cpp= taking a joined argument.  As a side-effect, the
> Negative markers on -cpp (public option to the driver, no argument)
> and -nocpp will now be effective (prune_options ignores all options
> marked Joined, so the Negative markers would not previously have done
> anything).
>   

Oh! Well spotted --  -no-cpp should work ...

> Bootstrapped with no regressions on x86_64-unknown-linux-gnu.  OK to
> commit?
>   

OK. Thanks for the patch!

Tobias

> 2010-07-28  Joseph Myers  <joseph@codesourcery.com>
>
> 	* lang.opt (cpp): Remove Joined and Separate markers.
> 	(cpp=): New internal option.
> 	* lang-specs.h (F951_CPP_OPTIONS): Generate -cpp= option.
> 	* cpp.c (gfc_cpp_handle_option): Handle OPT_cpp_ instead of
> 	OPT_cpp.
>
>

On Thu, Jul 29, 2010 at 1:31 AM, Joseph S. Myers
<joseph@codesourcery.com> wrote:
> I think my option handling patch series is now quite close to being
> able to make the driver share the option processing machinery of the
> core compilers.
>
> There are of course options accepted by the driver but not the core
> compilers, or by the core compilers but not the driver.  This is not
> in itself a problem - the machinery already handles options known to
> one front end but not another, and this is a similar case.  Indeed,
> almost all options for any of the core compilers should be accepted by
> the driver (and passed down via specs), while if a driver-only option
> is passed to cc1 it seems quite appropriate to warn or error that it
> is driver-only, like the existing warnings for other-front-end
> options.
>
> More of a problem, however, is options that are incompatible between
> the driver and the core compilers regarding whether they take
> arguments; adding support for such variations in option semantics
> seems like an undesirable complication, given that the interface to
> the core compilers is a purely internal matter that we can change for
> implementation convenience.
>
> Thus, I have reviewed all 71 options files for options with such
> incompatibilities.  Several oddities have come to light that are clear
> bugs that I will fix in due course, plus two clear incompatibilities
> that need addressing before the option-processing machinery can be
> shared:
>
> * The Fortran -cpp option takes no argument as an option to the
>  driver, but takes an argument as an option to f951.
>
> * common.opt unconditionally supports the -G option (-Gn and -G n,
>  small data size).  This option is passed down by specs on some but
>  not all targets, and SWITCH_TAKES_ARG controls whether the driver
>  thinks -G has an argument on a given target.  On some targets not
>  passing it to cc1, there is instead a -G option with no argument
>  that specs pass to the *linker*, which is of course incompatible
>  with the driver knowing about the -G option from common.opt on such
>  systems.
>
> This patch fixes the first of these issues, by changing the internal
> -cpp option to -cpp= taking a joined argument.  As a side-effect, the
> Negative markers on -cpp (public option to the driver, no argument)
> and -nocpp will now be effective (prune_options ignores all options
> marked Joined, so the Negative markers would not previously have done
> anything).
>
> Bootstrapped with no regressions on x86_64-unknown-linux-gnu.  OK to
> commit?

Together with LTO we see issues when frontend specific arguments
are passed down to lto1, like the fortran frontend -ffixed-* args
which conflicts with the common -ffixed-X.  Like PRs 41844.
Is there a chance, with your changes, to filter out all frontend
handled options when generating COLLECT_GCC_OPTIONS?

Richard.

> 2010-07-28  Joseph Myers  <joseph@codesourcery.com>
>
>        * lang.opt (cpp): Remove Joined and Separate markers.
>        (cpp=): New internal option.
>        * lang-specs.h (F951_CPP_OPTIONS): Generate -cpp= option.
>        * cpp.c (gfc_cpp_handle_option): Handle OPT_cpp_ instead of
>        OPT_cpp.
>
> Index: gcc/fortran/cpp.c
> ===================================================================
> --- gcc/fortran/cpp.c   (revision 162620)
> +++ gcc/fortran/cpp.c   (working copy)
> @@ -354,7 +354,7 @@ gfc_cpp_handle_option (size_t scode, con
>       result = 0;
>       break;
>
> -    case OPT_cpp:
> +    case OPT_cpp_:
>       gfc_cpp_option.temporary_filename = arg;
>       break;
>
> Index: gcc/fortran/lang.opt
> ===================================================================
> --- gcc/fortran/lang.opt        (revision 162620)
> +++ gcc/fortran/lang.opt        (working copy)
> @@ -173,9 +173,13 @@ Fortran Warning
>  Warn about unused dummy arguments.
>
>  cpp
> -Fortran Joined Separate Negative(nocpp)
> +Fortran Negative(nocpp)
>  Enable preprocessing
>
> +cpp=
> +Fortran Joined Negative(nocpp) Undocumented
> +; Internal option generated by specs from -cpp.
> +
>  nocpp
>  Fortran Negative(cpp)
>  Disable preprocessing
> Index: gcc/fortran/lang-specs.h
> ===================================================================
> --- gcc/fortran/lang-specs.h    (revision 162620)
> +++ gcc/fortran/lang-specs.h    (working copy)
> @@ -1,6 +1,6 @@
>  /* Contribution to the specs for the GNU Compiler Collection
>    from GNU Fortran 95 compiler.
> -   Copyright (C) 2002, 2003, 2004, 2005, 2006, 2007, 2008
> +   Copyright (C) 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2010
>    Free Software Foundation, Inc.
>
>    This file is free software; you can redistribute it and/or modify
> @@ -30,7 +30,7 @@
>  /* Options that f951 should know about, even if not preprocessing.  */
>  #define CPP_FORWARD_OPTIONS "%{i*} %{I*} %{M*}"
>
> -#define F951_CPP_OPTIONS    "%{!nocpp: -cpp %g.f90 %{E} %(cpp_unique_options) \
> +#define F951_CPP_OPTIONS    "%{!nocpp: -cpp=%g.f90 %{E} %(cpp_unique_options) \
>                             %{E|M|MM:%(cpp_debug_options) " CPP_ONLY_OPTIONS \
>                             " -fsyntax-only};: " CPP_FORWARD_OPTIONS "}"
>  #define F951_OPTIONS        "%(cc1_options) %{J*} \
>
> --
> Joseph S. Myers
> joseph@codesourcery.com
>

On Thu, 29 Jul 2010, Richard Guenther wrote:

> Together with LTO we see issues when frontend specific arguments
> are passed down to lto1, like the fortran frontend -ffixed-* args
> which conflicts with the common -ffixed-X.  Like PRs 41844.
> Is there a chance, with your changes, to filter out all frontend
> handled options when generating COLLECT_GCC_OPTIONS?

If the required information is in the .opt files, no doubt it could be 
implemented, though I do not necessarily expect to convert everything 
using struct switchstr in gcc.c to use the same structures as the core 
compiler.