> On Sep 14, 2023, at 4:57 PM, Andrew Pinski <pins...@gmail.com> wrote:
>
> On Thu, Sep 14, 2023 at 1:50 PM Qing Zhao via Gcc-patches
> <gcc-patches@gcc.gnu.org> wrote:
>>
>>
>>
>>> On Sep 14, 2023, at 12:18 PM, Xi Ruoyao <xry...@xry111.site> wrote:
>>>
>>> On Thu, 2023-09-14 at 15:57 +0000, Qing Zhao via Gcc-patches wrote:
>>>> 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?
>>>
>>> It only says the pointers cannot overflow, not the pointers are signed.
>>>
>>> printf("%d\n", (char *)(intptr_t)-1 > (char *)(intptr_t)1);
>>>
>>> produces 1 instead of 0. Technically this is invoking undefined
>>> behavior and a conforming implementation can output anything. But
>>> consider a 32-bit bare metal target where the linker can locate a "char
>>> x[512]" at [0x7fffff00, 0x80000100). The standard then requires &x[512]
>>>> &x[0], but if we do a signed comparison here we'll end up "&x[512] <
>>> &x[0]", this is non-conforming.
>>
>> So, are both the above examples showing that pointer based comparisons are
>> similar as unsigned integer comparison? -:)
>> Do we have examples on treating the pointer arithmetic as signed integer
>> arithmetic? (Really curious on this….)
>>
>> But anyway, if we cannot treat pointer type consistently as signed or
>> unsigned, shall we still need to catch pointer overflow?
>>
>> Currently, In GCC, we have -fsanitize=signed-integer-overflow to catch
>> signed integer overflow.
>> But we don’t have options to catch unsigned integer overflow and pointer
>> overflow.
>>
>> Shall we add two more options to catch unsigned integer overflow and pointer
>> overflow, like:
>>
>> -fsanitize=unsigned-integer-overflow
>> -fsanitize=pointer-overflow
>>
>> CLANG already provided -fsanitize=unsigned-integer-overflow. GCC might need
>> to do the same.
>
> NO. There is no such thing as unsigned integer overflow. That option
> is badly designed and the GCC community has rejected a few times now
> having that sanitizer before. It is bad form to have a sanitizer for
> well defined code.
Even though unsigned integer overflow is well defined, it might be
unintentional, shall we warn user about this?
>
> Now -fsanitize=pointer-overflow is already there for GCC which was
> added in r8-2238-gc9b39a4955f56fe609ef5478 . LLVM/clang also provides
> it in the same timeframe too .
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80998
Got it. Thanks a lot for the info.
Qing
>
> Thanks,
> Andrew
>
>>
>> And both Clang and GCC might also need to add -fsanitize=pointer-overflow?
>>
>>> IIUC, pointers are not integers, at all. If we treat them as integers
>>> in the brain we'll end up invoking undefined behavior sooner or later.
>>> Thus the wrapping/overflowing behavior of pointer is controlled by a
>>> different option than integers.
>>
>> However, the wrapping/overflowing behavior of pointers is still based on the
>> corresponding integer(or unsigned integer) wrapping/overflowing, right?
>> Do we have special pointer wrapping/overflowing?
>>
>> Qing
>>
>>>
>>> --
>>> Xi Ruoyao <xry...@xry111.site>
>>> School of Aerospace Science and Technology, Xidian University
