> On 28 May 2026, at 00:15, H.J. Lu <[email protected]> wrote:
>
> On Thu, May 28, 2026 at 7:11 AM Iain Sandoe <[email protected]> wrote:
>>
>>
>>
>>> On 27 May 2026, at 23:41, H.J. Lu <[email protected]> wrote:
>>>
>>> default_stack_protect_guard calls
>>>
>>> lang_hooks.types.type_for_mode (ptr_mode, 1);
>>>
>>> to get an integer type for __stack_chk_guard which is declared as a
>>> global symbol of type uintptr_t. For 32-bit systems, uintptr_t may
>>> be either unsigned int or unsigned long int. On 32-bit Darwin, we get
>>>
>>> $ cat /tmp/x.c
>>> __UINTPTR_TYPE__ __stack_chk_guard = 0x1000;
>>> $ ./xgcc -B./ -S /tmp/x.c -m32
>>> /tmp/x.c:1:18: error: conflicting types for ‘__stack_chk_guard’; have
>>> ‘long unsigned int’
>>> 1 | __UINTPTR_TYPE__ __stack_chk_guard = 0x1000;
>>> | ^~~~~~~~~~~~~~~~~
>>> cc1: note: previous declaration of ‘__stack_chk_guard’ with type ‘unsigned
>>> int’
>>> $
>>>
>>> since lang_hooks.types.type_for_mode returns unsigned int while Darwin's
>>> uintptr_t is unsigned long int. Update default_stack_protect_guard to
>>> check UINTPTR_TYPE to get unsigned integer type for uintptr_t instead.
>>>
>>> gcc/c-family/
>>>
>>> PR c/125226
>>> * targhooks.cc (default_stack_protect_guard): Check UINTPTR_TYPE
>>> to get unsigned integer type for uintptr_t.
>>
>> maybe making uintptr_type_node available would make the code smaller
>> overall?
>
> That will be a much bigger change.
It’s already computed for c-family (in c_common_nodes_and_builtins and
saved in c_global_trees) - so it’s already available to c-family.
Assuming that the stack protector could be used by non-c-family languages
then moving the computation to tree.cc/build_common_tree_nodes
<http://tree.cc/build_common_tree_nodes>
and the node to global_trees (c.f. size_type_node, ptr_type_node et . al)
seems plausible - maybe I miss something, Jason?
Iain
>
>> Iain
>>
>>
>>>
>>> OK for mastter?
>>>
>>> Thanks.
>>>
>>> --
>>> H.J.
>>> <0001-SSP-Check-UINTPTR_TYPE-to-get-uintptr_t-type.patch>
>>
>
>
> --
> H.J.
