> On Sep 14, 2023, at 11:12 AM, Richard Biener <richard.guent...@gmail.com>
> wrote:
>
>
>
>> Am 14.09.2023 um 17:01 schrieb Qing Zhao <qing.z...@oracle.com>:
>>
>> Thanks for the info.
>>
>>> On Sep 14, 2023, at 10:06 AM, Richard Biener <richard.guent...@gmail.com>
>>> wrote:
>>>
>>>> On Thu, Sep 14, 2023 at 3:42 PM Qing Zhao via Gcc-patches
>>>> <gcc-patches@gcc.gnu.org> wrote:
>>>>
>>>> Hi,
>>>>
>>>> I have several questions on these options:
>>>>
>>>> 1.are pointers treated as signed integers in general? (I thought that
>>>> pointers are addresses to the memory, should be treated as unsigned
>>>> integer…)
>>>> 2. If Yes, why?
>>>> 3. why a separate option for pointesr -fwrapv-pointer in addition to
>>>> -fwrapv if they are treated as signed integers?
>>>
>>> Pointers are unsigned, they might sign-extend to Pmode though.
>> If they are unsigned, why they are sign-extend to Pmode? Is there any
>> special reason for this?
>
> Some targets require this. See POINTERS_EXTEND_UNSIGNED
Okay, I see.
>
>> In another word, can we consistently treat pointers as unsigned?
>
> We do, but on GIMPLE it doesn’t matter.
Currently, GCC behaves as following:
/* True if overflow wraps around for the given integral or pointer type. That
is, TYPE_MAX + 1 == TYPE_MIN. */
#define TYPE_OVERFLOW_WRAPS(TYPE) \
(POINTER_TYPE_P (TYPE) \
? flag_wrapv_pointer \
: (ANY_INTEGRAL_TYPE_CHECK(TYPE)->base.u.bits.unsigned_flag \
|| flag_wrapv))
/* True if overflow is undefined for the given integral or pointer type.
We may optimize on the assumption that values in the type never overflow.
IMPORTANT NOTE: Any optimization based on TYPE_OVERFLOW_UNDEFINED
must issue a warning based on warn_strict_overflow. In some cases
it will be appropriate to issue the warning immediately, and in
other cases it will be appropriate to simply set a flag and let the
caller decide whether a warning is appropriate or not. */
#define TYPE_OVERFLOW_UNDEFINED(TYPE) \
(POINTER_TYPE_P (TYPE) \
? !flag_wrapv_pointer \
: (!ANY_INTEGRAL_TYPE_CHECK(TYPE)->base.u.bits.unsigned_flag \
&& !flag_wrapv && !flag_trapv))
The logic above seems treating the pointer default as signed integer, right?
Qing
>
>>> -fwrapv-pointer is to enable wrapping over zero,
>>
>> If we always treat pointers are unsigned, then we don’t need the
>> -fwrapv-pointer anymore, right?
>
> No, the naming is just ‚bad‘
>
>>
>>> we don't have many places using this, ISTR kernel folks requested to
>>> disable specific folding - digging in history
>>> might reveal the case/PR.
>>
>> Do you mean that this -fwrapv-pointer was introduced for kernel?
>
> I think it was introduced when removing the separate fstrict-overflow flag
> and since that covered also some pointer transforms the wraps-pointer flag
> was introduced.
>
>>
>> I will try to dig a little bit here.
>>
>> thanks.
>>
>> Qing
>>>
>>> Richard.
>>>
>>>> Thanks for your help.
>>>>
>>>> Qing
>>>>
>>
