> On 28 May 2026, at 08:08, H.J. Lu <[email protected]> wrote:
>
> On Thu, May 28, 2026 at 3:05 PM Iain Sandoe <[email protected]> wrote:
>>
>>
>>
>>> 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.
>>
>
> It is only done once:
>
> static GTY(()) tree stack_chk_guard_decl;
>
> tree
> default_stack_protect_guard (void)
> {
> tree t = stack_chk_guard_decl;
>
> if (t == NULL)
> {
> Check UINTPTR_TYPE ...
> }
>
Ah. OK .. I was looking at the patch originally attached, I guess you updated
it.
Iain
> --
> H.J.
