On 7/15/24 9:19 PM, Kewen.Lin wrote:
> on 2024/7/16 04:30, Peter Bergner wrote:
>> On 7/11/24 1:24 AM, Kewen.Lin wrote:
>>> Sorry for the confusion, I meant for most target options when we emit some
>>> error
>>> message meanwhile we also unset it, such as:
>>>
>>> if (TARGET_CRYPTO && !TARGET_ALTIVEC)
>>> {
>>> if (rs6000_isa_flags_explicit & OPTION_MASK_CRYPTO)
>>> error ("%qs requires %qs", "-mcrypto", "-maltivec");
>>> rs6000_isa_flags &= ~OPTION_MASK_CRYPTO;
>>> }
>>
>> That is not what is happening here though. The code here to disable
>> crypto is for the case where crypto is enabled implicitly, via say
>> -mcpu=power8, but the user has also explicitly disabled Altivec which
>> crypto depends on. In that case, we do not emit an error or warning and
>
> But if it's just for the case implicit enabling, the unmask should be
> in an else arm and not for both implicit and explicit, the code still does
> unmasking for explicit enabling. Since it's very unlikely to cause some
> unexpected behaviors in following processing even in future, it's your call.
> :)
I think that is just Mike's coding style. Yes, the clearing of the flag
could be in an else block, but clearing it even in the error case is
harmless, since we're going to emit an error and exit anyway.
Peter
