This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH (trunk rev.119231): ability to disable an option at configure time


Daniel Jacobowitz wrote:

> I think you've missed my point.  If an option really needs to be
> disabled at build time - I think this is a very bad idea in most cases
> but there might be a valid case - then the flag variable should exist
> as normal but the feature be forced to off after options processing,
> so that we can inform the user.

I think it's reasonable to have a mechanism to hard-wire flags at
configure-time.  For example, a compiler designed to be used on a
particular system could disable ABIs that aren't useful on that system,
which would help avoid users accidentally trying to use that ABI.  And,
in the process, the compiler itself a little smaller or faster.  IIRC,
the PowerPC back end has multiple config/*.h files depending on whether
you want SPE/E500/64-bit etc., since there is a compile-time cost
associated with having these available; the mechanism proposed would
make this same kind of tradeoff more generally available.

I think that in this mode the flag variable should become a preprocessor
define set to its hard-wired value.  Then, "if (flag_foo)" still works,
but will be optimized away at compile time.  As you say, we want the
--help output to see the flag, and we want it to be recognized by option
processing, and an error issued if the user sets it to a value other
than that hard-wired in.  So, in the option processing code itself,
flag_foo could become flag_foo_check, so that it can still be set and
checked.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]