On Thu, May 28, 2026 at 3:14 PM Iain Sandoe <[email protected]> wrote: > > > > > 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 >
It has always been done lazily. I didn't change it. -- H.J.
