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. :)
BR,
Kewen
> we silently disable crypto. This is similar to -mcpu=power8 -mno-altivec
> where we silently disable VSX. The other cases you showed are of similar
> scenarios.
>
> In my ROP code, we know ROP was explicitly enabled (it is never turned on
> implicitly with any -mcpu= option) and the target cpu and/or ABI does
> not support it, so there's nothing more to do, other than to emit an error.
> There is no matching implicit use case where we silently disable ROP as
> there was in your case above. Therefore, I think the code as I showed it
> is correct as is...other than the code snipit location, which I have moved
> and am testing now.
>
> Peter
>
>
>
