[Bug driver/48524] spec language does not cover switches with separated form
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48524 Manuel López-Ibáñez changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #9 from Manuel López-Ibáñez --- Is this fixed? Can we close it?
[Bug driver/48524] spec language does not cover switches with separated form
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48524 Ryan Hill changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #10 from Ryan Hill --- As far as we're concerned it is.
[Bug driver/48524] spec language does not cover switches with separated form
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48524 --- Comment #8 from Joseph S. Myers jsm28 at gcc dot gnu.org 2012-02-08 21:37:57 UTC --- Author: jsm28 Date: Wed Feb 8 21:37:50 2012 New Revision: 184022 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=184022 Log: 2012-02-08 Magnus Granberg zo...@gentoo.org PR driver/48524 * gcc.c (switch_matches) Support switches with separated form, -D and -U. testsuite: * gcc.dg/pr48524.c: New test. * gcc.dg/pr48524.spec: New spec file for test. Added: trunk/gcc/testsuite/gcc.dg/pr48524.c trunk/gcc/testsuite/gcc.dg/pr48524.spec Modified: trunk/gcc/ChangeLog trunk/gcc/gcc.c trunk/gcc/testsuite/ChangeLog
[Bug driver/48524] spec language does not cover switches with separated form
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48524 Magnus Granberg zorry at gentoo dot org changed: What|Removed |Added Attachment #26124|0 |1 is obsolete|| --- Comment #7 from Magnus Granberg zorry at gentoo dot org 2011-12-18 20:11:32 UTC --- Created attachment 26128 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26128 switches with separated form -D and -U Same patch but with a testcase. Tested on Gentoo with snapshot 4.7-20111217
[Bug driver/48524] spec language does not cover switches with separated form
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48524 --- Comment #5 from Magnus Granberg zorry at gentoo dot org 2011-12-17 20:30:17 UTC --- Created attachment 26122 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26122 switches with separated form -D and -U This patch make the -D and -U switches with separated form work in the spec language. Tested on Gentoo with the spec as in comment 2.
[Bug driver/48524] spec language does not cover switches with separated form
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48524 Magnus Granberg zorry at gentoo dot org changed: What|Removed |Added Attachment #26122|0 |1 is obsolete|| --- Comment #6 from Magnus Granberg zorry at gentoo dot org 2011-12-17 21:13:58 UTC --- Created attachment 26124 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26124 switches with separated form -D and -U fix typos in the last patch
[Bug driver/48524] spec language does not cover switches with separated form
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48524 Ryan Hill dirtyepic at gentoo dot org changed: What|Removed |Added Severity|normal |enhancement
[Bug driver/48524] spec language does not cover switches with separated form
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48524 Mike Frysinger vapier at gentoo dot org changed: What|Removed |Added CC||toolchain at gentoo dot org --- Comment #4 from Mike Frysinger vapier at gentoo dot org 2011-04-12 02:22:12 UTC --- a few test cases would cover that aspect i'd think
[Bug driver/48524] spec language does not cover switches with separated form
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.
[Bug driver/48524] spec language does not cover switches with separated form
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48524 --- Comment #2 from Ryan Hill dirtyepic at gentoo dot org 2011-04-09 18:51:20 UTC --- Sorry, i just wanted a trivial example. The actual rule we use is %{!D_FORTIFY_SOURCE:%{!D_FORTIFY_SOURCE=*:%{!U_FORTIFY_SOURCE:-D_FORTIFY_SOURCE=2}}} but this is just one example of several. The reason we use specs instead of just changing the default is so we can easily bypass them at runtime. This allows us, for example, to have a single compiler for both normal and hardened profiles. I understand what you're saying, but it still seems like an omission to me to not have a way to match switches with separate arguments. Surely this isn't the only case where this is useful?
[Bug driver/48524] spec language does not cover switches with separated form
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48524 --- Comment #3 from joseph at codesourcery dot com joseph at codesourcery dot com 2011-04-10 00:27:28 UTC --- On Sat, 9 Apr 2011, dirtyepic at gentoo dot org wrote: Sorry, i just wanted a trivial example. The actual rule we use is %{!D_FORTIFY_SOURCE:%{!D_FORTIFY_SOURCE=*:%{!U_FORTIFY_SOURCE:-D_FORTIFY_SOURCE=2}}} but this is just one example of several. The reason we use specs instead of just changing the default is so we can easily bypass them at runtime. This allows us, for example, to have a single compiler for both normal and hardened profiles. I understand what you're saying, but it still seems like an omission to me to not have a way to match switches with separate arguments. Surely this isn't the only case where this is useful? The same principle applies that if you wish to submit a patch to add such a feature it is desirable to have a (properly functional) use case in FSF GCC, as code with no such use case is liable to be removed in cleanups.