https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41055
--- Comment #9 from H. Peter Anvin <hpa at zytor dot com> --- I can confirm this bug is still present as of gcc 8.2.1. I have attached a test case which clearly shows __udivdi3 called with the regparm convention, but libgcc definitely does not expect it: objdump -dr `gcc -m32 -march=i386 -mregparm=3 -O3 -fomit-frame-pointer --print-libgcc` 00000000 <__udivdi3>: 0: f3 0f 1e fb endbr32 4: 55 push %ebp 5: 57 push %edi 6: 56 push %esi 7: 53 push %ebx 8: 83 ec 1c sub $0x1c,%esp b: 8b 54 24 3c mov 0x3c(%esp),%edx f: 8b 6c 24 30 mov 0x30(%esp),%ebp 13: 8b 74 24 34 mov 0x34(%esp),%esi 17: 8b 5c 24 38 mov 0x38(%esp),%ebx ... As far as I can tell, there are four possible options: a. Build a libgcc for any combination of runtime options. b. Add multiple functions to libgcc for each combination of runtime options which matter. c. Force using a single ABI for libgcc functions (in which case it might as well use the most efficient ABI, e.g. -mregparm=3 -freg-struct-return); as the libgcc functions are private to gcc anyway there is no reason they need to use the main calling convention. d. Emit these functions in a link-once section, similar to the way __x86.get_pc_thunk.* are generated. This has upsides and downsides: the upsides are that they are inherently correct, that they can rely on arch/optimize flags, a dynamic library can't get out of sync with the compiler if these functions are changed, and these functions can be marked hidden, which means that they can be called directly. Downsides are link time and some heavy lifting in implementation. It also means that each dynamic library carries its own copy, but since libgcc already marks its symbols HIDDEN, this is already the case.
