> On 28 May 2026, at 07:54, H.J. Lu <[email protected]> wrote:
>
> On Thu, May 28, 2026 at 2:45 PM Iain Sandoe <[email protected]> wrote:
>>
>>
>>
>>> 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?
>>
>
> rust also defines intptr_type_node and uintptr_type_node:
>
> c-family/c-common.h: CTI_INTPTR_TYPE,
> c-family/c-common.h: CTI_UINTPTR_TYPE,
> c-family/c-common.h:#define intptr_type_node
> c_global_trees[CTI_INTPTR_TYPE]
> c-family/c-common.h:#define uintptr_type_node
> c_global_trees[CTI_UINTPTR_TYPE]
> rust/backend/rust-tree.h: CTI_INTPTR_TYPE,
> rust/backend/rust-tree.h: CTI_UINTPTR_TYPE,
> rust/backend/rust-tree.h:#define intptr_type_node
> c_global_trees[CTI_INTPTR_TYPE]
> rust/backend/rust-tree.h:#define uintptr_type_node
> c_global_trees[CTI_UINTPTR_TYPE]
>
> I guess they can be moved to tree-core.h as TI_INTPTR_TYPE/TI_UINTPTR_TYPE.
> This will be a much bigger change with rust testing.
well, not my call, on that (just a suggestion)…
… but if you leave it as computed locally, maybe do it once lazily and save
the result - to avoid all those string comparisons being repeated for every
check.
Iain
>
>
> --
> H.J.
