> Am 16.10.2025 um 17:03 schrieb Richard Biener <[email protected]>:
>
>
>
>>> Am 16.10.2025 um 16:56 schrieb Sandra Loosemore <[email protected]>:
>>>
>>> On 10/15/25 23:06, Richard Biener wrote:
>>> By policy we never remove options but instead mark them as ignored.
>>> This also prrevents accidental reuse in the future with possibly
>>> different semantics.
>>
>> OK, I can do that instead for this option, and any others I find that are
>> clearly obsolete.
>>
>> I have a related question, though. There are quite a number of -f options
>> that take an argument but that don't have RejectNegative, for instance
>> -fanalyzer-verbosity=. I was doing some experiments last evening and found
>> that the driver passes -fno-analyzer-verbosity=0 through to cc1, but with
>> any other argument gives cc1 the *positive* form of the option with that
>> argument, e.g. -fno-analyzer-verbosity=4 is canonicalized to
>> -fanalyzer-verbosity=4. I think this is not intentional behavior and is not
>> useful to users. Is adding RejectNegative (or changing the options
>> processing to assume it for all options that take an argument) also
>> forbidden since it essentially removes (useless/confusing) options?
>
> We’ve added RejectNegative in the past IIRC, so that’s OK. For such options
> there should be a separate fno-analyzer-verbosity (without =) aliasing one of
> the positive options if that makes sense
To clarify, I think we want in General have a way to turn off an option turned
on by a preceding flag. Like -fsanitize=address,undefined
-fno-sanitize=undefined turning off undefined sanitize (not sure if it works
this way). The current behavior as you describe for analyzer-verbosity is
simply broken.
Richard
> Richard
>
>>
>> -Sandra
