Re: Question on -fwrapv and -fwrapv-pointer

[Richard Biener via Gcc-patches]

> 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

> In another word, can we consistently treat pointers as unsigned? 

We do, but on GIMPLE it doesn’t matter.

>> -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
>>> 
>