This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug driver/48524] spec language does not cover switches with separated form
- From: "joseph at codesourcery dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Sat, 9 Apr 2011 11:28:39 +0000
- Subject: [Bug driver/48524] spec language does not cover switches with separated form
- Auto-submitted: auto-generated
- References: <bug-48524-4@http.gcc.gnu.org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48524
--- Comment #1 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2011-04-09 11:28:33 UTC ---
Specs are an internal GCC implementation detail, subject to change
whenever convenient for implementation purposes. (Whoever put
documentation for them in invoke.texi was wrong to do so - and as far as I
know, did not have FSF permission either for copying text from gcc.c under
one license to invoke.texi under another - the comment starting "Specs are
strings containing lines" is the proper documentation for specs.) My
recommendation in
<http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01486.html> for certain
broken -D specs in GCC was that any required semantics should be moved
into cc1. We have for a long time been moving away from defining built-in
macros in specs, towards defining them based on actual logical state
derived from option processing. In any case if you wish to submit a patch
for some new specs feature I would suggest you include the
--enable-fortify-source=2 or similar configure option with it to provide
some actual use for that feature in GCC. Note that the spec you give
appears wrong in that any -D_FORTIFY_SOURCE or -D_FORTIFY_SOURCE=<value>
option passed by the user should presumably also disable a default
-D_FORTIFY_SOURCE=2 option; maybe you actually want an
if-macro-not-defined spec function that covers all these cases.