HJ, Bootstrap on 32b Darwin (and 64b Darwin with 32b multilib) is still broken after more than three weeks,
It is reasonable to have a temporary break if there is a trivial typo or other fix that can be applied in a timely manner. However, in this case, it seems your initial design needed some amendment, and that means a more complex fix is needed - which needs additional review. Today I now faced two concurrent bootstrap breaks on some platform versions - this is just consuming time in a non-constructive manner. Please revert your changes until you have an agreed design for this facility. thanks Iain > On 16 May 2026, at 00:52, H.J. Lu <[email protected]> wrote: > > On Mon, May 11, 2026 at 4:49 PM Iain Sandoe <[email protected]> wrote: >> >> Hi HJ >> >>> On 8 May 2026, at 11:05, 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 >> >> FWIW, I suspect that, at the very least, Windows does the same. >> >>> $ 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. >>> >>> Add LANG_HOOKS_TYPE_FOR_MODE_KIND to specify signed or unsigned integer >>> type for pointer and update default_stack_protect_guard to call >>> >>> lang_hooks.types.type_for_mode_kind >>> (ptr_mode, 1, KIND_IS_INTEGER_FOR_POINTER); >>> >>> to get unsigned integer type for pointer. >> >> OK. So this does fix bootstrap on Darwin platform versions with 32b >> mulitilibs (and >> 32b hosts). However there is still work to do on the testcases (ABI-related >> differences >> at least). >> >> It seems rather excessive to need to add two target hooks for this small >> feature. >> >> We have C++ - could you not add a defaulted parameter to the original hook >> that >> would allow for querying a specific result for the mode type without needing >> to >> churn the code for every other use? > > The default function parameter doesn't work on function pointers: > > [hjl@gnu-tgl-3 tmp]$ cat x.cc > void (*foo) (int = 0); > [hjl@gnu-tgl-3 tmp]$ gcc -S x.cc > x.cc:1:18: error: default arguments are only permitted for function > parameters [-fpermissive] > 1 | void (*foo) (int = 0); > | ^ > [hjl@gnu-tgl-3 tmp]$ > >> thanks >> Iain >> >>> >>> gcc/ >>> >>> PR c/125226 >>> * langhooks-def.h (LANG_HOOKS_TYPE_FOR_MODE_KIND): New. >>> (LANG_HOOKS_FOR_TYPES_INITIALIZER): Add >>> LANG_HOOKS_TYPE_FOR_MODE_KIND. >>> * langhooks.h (type_kind): New enum. >>> (lang_hooks_for_types): Add type_for_mode_kind. >>> * targhooks.c (default_stack_protect_guard): Call >>> lang_hooks.types.type_for_mode_kind if not NULL. >>> >>> gcc/c-family/ >>> >>> PR c/125226 >>> * c-common.cc (c_common_type_for_mode): Renamed to ... >>> (c_common_type_for_mode_kind): This. Add an argument for type >>> kind. Return intptr_type_node/uintptr_type_node when asking >>> for integer type for pointers. >>> (c_common_type_for_mode): New. Call c_common_type_for_mode_kind >>> with KIND_IS_UNKNOWN. >>> * c-common.h: Include "langhooks.h". >>> (c_common_type_for_mode_kind): New prototype. >>> * c-objc-common.h (LANG_HOOKS_TYPE_FOR_MODE_KIND): New. >>> >>> gcc/cp/ >>> >>> PR c/125226 >>> * cp-objcp-common.h (LANG_HOOKS_TYPE_FOR_MODE_KIND): New. >> >> >>> >>> >>> -- >>> H.J. >>> <0001-c-c-Get-unsigned-integer-type-for-pointer.patch> >> > > > -- > H.J.
