On 5/28/26 4:59 PM, H.J. Lu wrote:
On Fri, May 29, 2026 at 2:05 AM Jason Merrill <[email protected]> wrote:
On 5/28/26 11:08 AM, H.J. Lu wrote:
On Thu, May 28, 2026 at 9:08 PM Jason Merrill <[email protected]> wrote:
On 5/27/26 6:41 PM, H.J. Lu 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.
OK for mastter?
If we're going to reuse the code from build_common_tree_nodes with a
different string macro, let's factor it out into a function in tree.cc
that gets called with SIZE_TYPE or UINTPTR_TYPE.
Like this?
Yes. I also wonder about targets that don't define UINTPTR_TYPE; we
might return NULL_TREE from the new function in that case and fall back
to type_for_mode in default_stack_protect_guard.
Jason
Fixed in v3 with:
if (UINTPTR_TYPE && targetm.stack_protect_guard_symbol_p ())
/* Get unsigned integer type for uintptr_t. */
t = unsigned_integer_tree_node_for_type (UINTPTR_TYPE);
else
t = ptr_type_node;
OK.
Jason
