On Wed, Aug 23, 2017 at 12:29 AM, Alexandre Oliva <aol...@redhat.com> wrote: > On Aug 21, 2017, Richard Biener <richard.guent...@gmail.com> wrote: > >> +gno-statement-frontiers >> +Common Driver RejectNegative Var(debug_nonbind_markers_p, 0) Init(2) >> +Don't enforce progressive recommended breakpoint locations. >> + >> +gstatement-frontiers >> +Common Driver RejectNegative Var(debug_nonbind_markers_p, 1) >> +Emit progressive recommended breakpoint locations. > >> others get away with a single flag and Init(-1). That is, >> -gstatement-frontiers >> should set it to 1 already and -gno- to 0. Why do you need the explicit >> entry for gno-..? > > All debug options that support negation seem to have adopted this idiom; > without it, the negated options end up misparsed as -g with an argument, > and then set_debug_level complains that "no-..." is not a number. > > The logic of matching the longest option name prefix doesn't seem to > work very well when options have a prefix that is also a valid option > with a Joined(OrMissing) argument. > > The same problem applies to -O: -Ono-fast is not parsed as a negative of > -Ofast, but as -O with no-fast as the argument, even though no > RejectNegative flag is present under Ofast.
Ah, like we don't have -no-g but only -g0. I guess that there's -fno- is somewhere hardcoded and -g isn't handled that way. Would need to amend the options machinery somehow (new flag, Negatable?). Thus ok as in your patch for now. Richard. > -- > Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/ > You must be the change you wish to see in the world. -- Gandhi > Be Free! -- http://FSFLA.org/ FSF Latin America board member > Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer
